Message-ID: <2058338667.92793.1397883071339.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_92792_1317591612.1397883071338" ------=_Part_92792_1317591612.1397883071338 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
When Google sends email, it sends it with a "Sender" of "= <user>@gmail.com" (or whichever domain you're registered in). Ch= anging your From address does NOTHING to change the Sender header (and enve= lope header) that Google Mail sends.
EZMLM checks the envelope and Sender header. These all need to match up = to your subscribed address or your email will be rejected.
This is not a bug.
Complain to Google. You are effectively sending email as john.smith@gmai= l.com while you subscribed with firstname.lastname@example.org (for example).
ezmlm-idx/qmail do not currently support parsing of SRS encoded emails o= ut of the box. Thus, neither do our lists.
ezmlm-idx/qmail do not currently support parsing of BATV encoded emails = out of the box. Thus, neither do our lists.
We have no finite timeline for fixing any of the issues above. It's simp= ly not a priority, and we have fixed resources for dealing with other issue= s.
The trivial solution is to disable some of the verification in EZMLM. Th= is would let more spam through for everyone else. Not going to happen.
If we use ezmlm-idx/qmail in a standard configuration, then our service = provider will support and manage the service. If we start adding random pat= ches, then they won't - this makes our life painful. We do not like pain.= p>