Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Sat, Aug 30, 2003 at 10:42:17AM +1000, Brian May wrote:
> On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote:
> > the point that you keep on missing is that TMDA and similar programs send
> > "confirmation" emails to innocent third-parties who did *NOT* send an
> > email.
> >
> > TMDA and all C-R systems are broken-by-design, just as many stupid end-user
> > "autoresponders" and AV-scanners that send notifications back to the forged
> > sender address are broken-by-design.
>
> You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail
> addresses is also broken?
no, i am not saying that.
> That is the idea behind autorespoonders after all, to tell the sender
> that his mail didn't get through because it didn't meet some required
> criteria.
the difference are :
1. a bounce is NOT the same thing as generating a new "notification" or
"confirmation" message.
2. with modern MTAs that can reject mail from spammers/spamware/viruses during
the SMTP session, there is no bounce message at all. by issuing a "5xx" reject
code during the smtp session, it leaves the task of bouncing the message up to
the sender....and very few (none, to my knowledge) virus or spamware programs
have any code at all to send bounces. they just ignore the reject and move on
to spamming the next victim address.
this is beneficial both to the mail server itself (which is not clogged up with
thousands of undeliverable bounces) and also to the poor bastard who has had
their address forged by spamware or virus.
reasons for rejecting during the smtp session include: unknown recipient, relay
access denied, blacklisting (open relay, dialup/dynamic pool, known spam domain
etc), local policies (message size, quota, etc), obvious spam/virus (e.g.
content-filtering) and many others.
3. it is reasonable and correct for an MTA to assume that the sender
address is correct. that is its job.
it is not at all reasonable for an anti-virus or anti-spam system to make that
assumption - almost all spam and most viruses are "from" forged addresses.
this has been known for years, it is absolutely inexcusable that any anti-virus
or anti-spam tool has been programmed without this knowledge in mind.
4. if an anti-virus or anti-spam mail system can NOT reject the mail during the
smtp session then it MUST NOT send any notification/bounce back to the sender.
the correct thing to do is to either tag the message and deliver it to the
recipient address (perhaps after removing or de-fanging any virus), or to
quarrantine it (and optionally send the *recipient* a notification message, or
just let them check their quarranitine box every so often).
> The other option which many people seem to want is to discard the E-Mail
> without giving either party any indication of what happened.
>
> E-Mail that looks suspicious can be valid mail at times, for instance
> somebody I knew tried to send a ZIP file that happened to be executable via
> E-Mail.
>
> Do you simply discard such E-Mails (which gives no indication that something
> went wrong), or do you try to contact the sender to indicate that something
> went wrong?
the answer to this is obvious:
you reject it and leave it up to the sending mta/client to deal with it.
if the sender is spamware or virus, there won't be any bounce message (nor
should there be).
if the sender is a legitimate client, then the user will be notified (usually
via a dialog box) and the message will stay in the outbound queue or be bounced
to the inbox or an error mbox.
if the sender is a mail server, then it will bounce the message back
to the original sender. if it was a legitimate email that bounced (e.g.
unknown recipient) then that is what is supposed to happen. the only time this
is a problem is when the sending MTA is an open relay, and the address was forged.
there isn't much that can be done about that, however bounces from an open
relay server will be rejected by any MTA that uses an open-relay blacklist (so no
bounce will be delivered to the forged address).
> One approach for instance would be to modify the SMTP standard, and say if a
> host accepts the E-Mail then it is guaranteed to get it to the destination
> (ie. it signal OK until the message has been delivered), but that would break
> store-and-forward capabilities of secondary mail servers.
that is pretty much the standard now, except that a host which accepts a
message MUST either deliver it (directly or forward it on to the next hop), or
it MUST bounce it.
that word "accept" is crucial, however. if you don't accept the message (i.e.
if you reject it with a 5xx reject code) then it's not your responsibility to
either deliver or bounce it...it is the responsibility of the sending client or
server.
> Even encryption does not help here, or at least I have not seen any proposals
> for any system that could scale to the Internet. GPG for instance only
> verifies the sender to the receiver, it could not be used to verify every
> sender to the MTAs involved.
encryption and authentication are basically irrelevant to this problem.
even if there is some replacement to smtp that does real authentication, there will
(for many years at least) be gateways between current SMTP and whatever the new
mail protocol is. these will be essential for email to work. they will also
ensure that the new protocol doesn't actually fix the problem.
craig
Reply to: