ietf-mxcomp
[Top] [All Lists]

Re: Input on identities

2004-04-03 16:11:04

Agreeing (mostly) with Aredridel here... I'm adding some additional discussion points for discussion.


--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.
 * 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: <>
 * 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)

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)
 * 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.


[MAIL FROM checking]
I believe that MAIL FROM is the simplest solution that will give enough
information to base further proposals on: In accepting responsibility
for bounce traffic, a sending system takes on enough burden that if the
MAIL FROM validity check passes, it's likely it's not faked.

Agreed! At least one "verified contact domain" is worlds better than none. Lot of good points (which I will snip, but I agree with them.)


What worries me most about From: checking without another layer
underneath is that I think new headers will have to be invented, or many
more semantics loaded on existing ones in regards to mailing lists:

  * Should From: joe(_at_)example(_dot_)com with Sender: 
joe(_at_)example(_dot_)org be
    accepted?
  * Should From: joe(_at_)example(_dot_)com with Responsible-Mailing-List: or
    Sender: ietf-mxcomp-owner(_at_)imc(_dot_)org be accepted?

RFC2476 mentions Sender: but it is not a strong requirement. Still, it is an existing RFC and perhaps we can lean on that when deciding what to do.

[http://www.rfc-editor.org/rfc/rfc2476.txt]
8.1.  Add 'Sender'
   The MSA MAY add or replace the 'Sender' field, if the identity of the
   sender is known and this is not given in the 'From' field.
   The MSA MUST ensure that any address it places in a 'Sender' field is
   in fact a valid mail address.

I interpret this (based on some other context in the document) that the MSA has a choice: leave the headers totally alone, or if they are checked, make sure the data is right. Since the MSA is the point where mail is (supposed to be) injected into the mail stream, AND the MSA is supposed to check identities, this is a very logical place to add Sender: data.

So, I think we have a logical argument if we decide to punch up the importance of Sender (or From: if Sender: is missing) which is mostly consistent with pre-existing RFC, and works the way many mail servers and mailing lists work now. In other words, Sender: is often ignored, because RFC2476 is not quite strong enough (and because many mail admins ignore RFC2476) but there is a precedent here, in writing, from 5+ years ago.


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.

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.



[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 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".

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 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.)


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.


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.



--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>