|
Re: Input on identities
2004-04-03 18:59:11
Greg Connor wrote:
[snip intro]
--Aredridel <aredridel(_at_)nbtsc(_dot_)org> wrote:
[HELO checking...]
Very true: easy and lightweight, but in my estimation, not as effective
as MAIL FROM would be.
Benefits:
* All machines would use a valid domain to send mail
* Verifiable that it is an authorized MTA for the domain it claims to
be
* Bogus HELO is often used to mislead people. Checking HELO for
obvious, outright forgery keeps MY domain from being mentioned
in a bogus message if I am not related to the sending client.
This may lead to a reduction in misdirected abuse reports.
Specifically, forged domains would not appear in Received headers and MTA logs.
* HELO is a logical "fallback" in the case of MAIL FROM: <>
If MAIL FROM: <> is not being widely abused today, adding another
layer might help to keep abusers from switching to MAIL FROM: <>
Agreed, we need some way to protect bounces. I don't think the alternative,
enforcing specific structure (DSN) on messages with "MAIL FROM: <>", is a
good idea. Much better to check HELO.
* HELO is currently pretty useless because it is not checked, but
encouraging server admins to use the right name can have long-term
benefits. (i.e. Take Back Your RFC2821 HELO! - If the data is often
wrong now, we can give an incentive for people to fix it over time.
If the data is only a "fallback" now, it could be eligible for
promotion to "primary" criteria status in a year or two, provided
we state that non-FQDN HELO is deprecated)
I think that providing a protection mechanism for HELO regardless of the
MAIL FROM: contents would be a good idea. Consider the following scenario:
1. Spammer owner of example.com with no association with example.net sets up
an MTA with 'HELO example.net'
2. Spammer creates MARID records allowing 'MAIL FROM: <*(_at_)example(_dot_)com>' from
that MTA.
3. Spammer spams using that MTA.
4. Abuse complaints pour into example.net and example.net's upstream about
the spam from 'their MTA' or 'an MTA on their network', respectively.
As for FQDN usage, RFC 2821 specifically requires FQDN usage in sections
2.3.5 ("Domain"), 4.1.1.1 ("EHLO/HELO"), and 5 ("Address Resolution and Mail
Handling"). Thus, non-FQDN HELO names don't need to be deprecated, they need
to be rejected at receiving MTAs.
Possible cons:
* No identity as related to the message itself -- such a system would
make a very weak foundation to base other checks on, unless one were
restrict MAIL FROM or From: to be part of the same domain as the
HELO, which is, I think, completely unreasonable.
* Large amount of bad data from HELO coming from badly configured
servers (like HELO localhost.localdomain or HELO NETBIOSNAME)
If HELO checking is beefed up, there is a chance of losing bounce
messages from these ill-configured machines (or ALL messages if
HELO is a primary method and not merely a fallback)
If we are going to talk about enforcing restrictions on the data sent in
protocol fields, doesn't it first make sense to enforce the syntactic and
semantic validity of that data; i.e. its conformance to RFC 2821?
* Need to exempt some MUAs from HELO checking - they may have bad names
or their names may be internally-known only. That's OK, MUAs should
send to MSAs, not directly to a remote MTA, per RFC2476.
Agreed here, that should not be something to worry about.
[MAIL FROM checking]
[Sender checking]
Agreement here, on both parts.
MUAs will have to be changed to support displaying the validated info,
likely, to have a benefit from From: checking -- as seen in Outlook
2003, one might see:
From: joe(_at_)example(_dot_)com, as relayed by the list
ietf-mxcomp(_at_)imc(_dot_)org
Agreed. Some MUAs show Sender: in some way but not as many as probably
should. My view is that I want to *encourage* MUA writers to use the
data (by checking it for correctness when From: can't be checked, for
example) and it looks like some are moving in this direction anyway.
BUT we don't want to *require* MUA changes for RFC-MARID2 to work.
I think the best we can do as it relates to MUAs is to ensure that they have
access to the most valid data possible. That's quantity and quality, and I'm
including any end-user filters in 'MUA'.
One way around this might be to allow receivers to modify the From:
header by adding (unverified) or even by adding a warning to the top of
the message body or first text part. That way if a receiving site has a
lot of users with old MUAs, and can't see Sender: data now, it can be
made more visible without modifying the MUA, and this can be turned off
later when the MUA is improved to show Sender: in a visible way.
I think the standard way such things are done on mailing lists is adding an
additional MIME part in front of any existing body. However, this is a
matter of local policy and something that I think implementors can come to a
consensus on without IETF assistance.
My only concern here would be if a message were received, modified, and then
relayed rather than delivered locally. Following this, the next mail host
would no longer have access to the 'pristine' message.
[in-addr.arpa checking]
What worries me the most about this sort of system is that it again
makes two classes of citizens on the net: Those who have end-to-end IP
connectivity, and those who have restrictions placed on what services
they may run.
This is true, I think, and it already happening to some extent...
known-dialup or known-dynamic space is treated with prejudice by AOL and
some others already. Bad or missing rDNS is already treated with
rejections in many places now.
I have experienced this first hand. If you look at Received headers in mail
coming from me, you'll see that my mail is routed through comcast.net's
'smarthost', because of that prejudicial treatment. Unfortunately, there are
certain issues with this arrangement. In particular, their outgoing hosts
have on occasion wound up on blacklists.
I am concerned, but not hugely so... since most of those affected are
residential machines that shouldn't be used to send mail directly.
Their ISP usually tells them to use the ISP.NET preferred mail host, and
their agreement usually says not to run "servers".
When they say servers, the common interpretation among users is 'systems
providing external services' i.e. FTP sites, web hosting, etc. I'm not sure
if designating such a machine as a domain's primary MX is in violation of
those terms.
I get around this at home by paying a little extra for static IP and
proper rDNS that I control, but if someone is doing stuff on the cheap
and they don't want to pay for "business class" service, they have the
choice of using the ISP's mailer. (In most cases, they already agreed
to do so ;)
In my situation, and that of many others as well, this is simply impossible.
There is nothing I could pay Comcast to provide a truly static IP, nor the
ability to control my own rDNS records. Right now, relaying through their
mailer works, for the most part, but I fear that could break in the future.
In general I think bad or missing rDNS is a problem... but it's unlikely
to get fixed by working around it and not trusting the data... the real
fix is to enforce in-addr restrictions (especially rDNS) and put more
pressure on people to fix it. Just ignoring the data because it's
sometimes bad now is a slippery slope, and from up here we can just
barely see where HELO has already slid way down :)
(This is not directly in response to what Aredridel wrote, but more in
response to general murmur that "some people don't have control over
their rDNS." I strongly support checking rDNS but I'm neutral on other
proposals like MTAMark or SS.)
Unfortunately, there really are no restrictions on that data. In particular,
RFC 1035 provides no normative text on the contents of .in-addr.arpa
specifying that host names in PTR records should exist or be consistent with
the forward resolution of those names.
I don't think we have any hope of putting rDNS PTR data to good use without
a lot of support from DNS-NG and the larger community.
As for MTAMark and SS, we might have a much easier time, because we can
specify its operation from a pretty low level.
It is also fairly limited in scope, since if an ISP wishes to control
what IPs may send mail, then they simply have to configure their routers
appropriately. (I'm aware that some brands of router make this difficult
or more resource intense than it need be, but that's a software issue
that's relatively easily remedied if a need is seen.)
Agreed. Publishing the policy in rDNS is interesting, but I would
prefer if the ISP itself would just ENFORCE its own policy and not
expect everyone else to do it. Block 25 to remote and remind everyone
to use 587. If you're at home and your work server doesn't have 587,
they need to fix that... they probably shouldn't be accepting your
message for relay on 25 anyway.
I agree that ISPs should enforce their own policy decisions. I also agree
that users pressuring their employers to offer access on 587 is a good
thing. However, I disagree with your statement that servers should not be
accepting mail for relay on 25. With appropriate access control (the full
range from IP checks to TLS client cert validation), this is just fine.
There is also a side issue of the HELO checking vs. the domains from
which it is sending email. A single SMTP transaction may process more
than one message within a single HELO prompt with the MAIL FROM values
for multiple domains. Therefore, it might be impossible to determine
whether network B has authorized the MTA when it is using network's A
domain name in HELO (for which it is authorized), while in fact it may
be relaying email from network B within that transaction.
I think that stems from trying to give to HELO some MAIL FROM-like
semantics.
I agree with this. The HELO name should identify the MTA by name. It
may not be related to the MAIL FROM or From: domain, and that's OK. The
HELO name should NOT! change depending on whose mail is being relayed.
I agree with this as well. Additionally, we may want to consider a method
whereby a domain specifies that servers whose HELO has a specific,
verifiable value are allowed to send using that domain. This would cover the
major case of most hosting providers that enforce outgoing mail restrictions.
Philip Miller
|
|