[Mimedefang] Email injection and the android 'email' app

[Dale Moore]

I am a recent mailing list subscriber.
I am a longtime user of mimedefang.

I'd like to discuss email injection, which is not specifically a mimedefang
issue, but I will use mimedefang to implement what I'm discussing.

I have had the philosophy that it is better to reject an email via
SMTP protocol (550 5.1.1 No Such user here) instead of accepting an
email then later sending a Delivery Status Notification (DSN) that an email
could not be delivered.

That philosophy of early rejection is independent of
  - whether the client had authenticated or not, and/or
  - whether the email was for the local site or not.

This philosophy reduces network traffic, reduces mis-directed
DSN blowback (faked envelope mail from), and is just  a cleaner
way of doing things.

A most curious behavior that I'm seeing is with the Android email app.
When an android user, using the default 'email' app,
attempts to send email to user at this.site.example.com but the
user mistypes the email address as nosuchuser at this.site.example.com
the SMTP server for my domain (this.site.example.com) will respond with 
  550 5.1.1 No Such mailbox here <nosuchuser at this.site.example.com> 
It responds with failure because the smtp server knows the local
domain this.site.example.com very well because it is the local domain.
And it knows all of the email addresses within that domain.
And it knows that nosuchuser at this.site.example.com is not valid.
It only makes sense to me to reject this email at this point.

The android 'email' app, will NOT take this 'permanent' failure as definitive,
and instead try again shortly to resend the email.   The email remains the
the app's 'Outbox' .  I currently have dozens of remote android client
that connect to my smtp server that regularly attempt to send their
same mis-addressed email dozens of times a day for weeks on end.

My guess is that this email client application wants my SMTP server to
always accept the email and send a DSN upon discovery of a problem.

We currently have several per account email settings stored in our
ldap directory that my mimedefang milters reference. These settings include
  - Spam scoring thresholds
  - greylisting settings
we are considering one that would do the following
  - get the authenticated user id ($main::SendmailMacros{auth_authen})
  - retrieve their LDAP bouce settings
  - Use this bounce setting to decide whether to bounce or send a DSN.

Another option to attempt to solve this problem, is if my milters see this
behavior more times than some configurable threshold (say 10 times from
the same IP/envelope from/rcpt to/) is to 
  - adjust the servers behaviour by accepting the email and
  - send a DSN that the email was probably mis-addressed.
That would cause the apps nagging to eventually stop, but at the expense
of a non-immediate feedback to the app user that he or she cant type.

Another option is some combination of the above.

Currently, to deal with this problem,  I'm 
  - manually scanning the logs picking out such behavior
  - personally notifying the users that their email isnt going out and why
  - helping them put their droid in airplane mode
  - helping them remove the offending message from their 'Outbox'
  - helping them put their droid out of airplane mode

If your opinion is that the android app is wrong, I'll agree.  But it is becoming
so pervasive, we must find a better way of accomodating this email client app.
There are too many android users.  We cant try to convince them that they should
use a different email app or adjust their settings for composing or reading email.
I might as well hold back the tide as ask them to change their behavior.
I myself am an android app user.

Your ideas are appreciated.  You can send your ideas  to me directly and I will
summarize in a week.  Or you can send them to this list.

Dale Moore