Diana:
I have some opinions on this matter that may or may not care to read:
1) Computers are designed to do what we ask them to. When programmers
and administrators start to get TOO SMART, and second-guess the "users",
problems often arise. When you provide to QMail a message envelope with
3 recipients, it's going to deliver 3 copies -- regardless of who they
are addressed to. GMail is consolidating duplicate recipients to reduce
their storage requirements -- and because they get TONS of SPAM
addressed in odd ways trying to defeat their security measures. And if
you think Exchange is so good, try using in-line attachments these days
(the message will arrive, the attachment dutifully removed because MS
unilaterally decided in-line attachments cause problems and they won't
allow them anymore).
2) If the end-users of your business are flummoxed by duplicate e-mail
messages, you should seriously consider taking away their computers and
access to email at all. Really? They can deal with the 300 SPAM messages
in their Junk folders just fine, but might be confused by this
announcement message appearing more than once.
3) I have one word for your programmer: *UNIQ*
Send the contents of his mail message through *UNIQ *(which will
combine any 2 or more contiguous lines that are exactly alike into just
1 line)
The only real drawback would be that triple-spacing (2 blank lines)
will become double-spacing (1 blank line), etc... but the duplicate
receipts should be gone!
*UNIQ *is BASIC *nix -- a typical example (in a class) being "given this
list of vegetables in bags on this truck, how many different vegetables
are there? -- and the answer is a simple sort piped into a uniq (/sort
file | uniq/) which is then piped into a counting program (usually, wc
-- to the final command is: /sort file | uniq | wc -l/ )
Just my thoughts...
Dan
IT4SOHO
(Am I being cranky today??)
On 7/24/2014 10:12 AM, Diana Calder wrote:
Wednesday, July 23, 2014, 3:45:47 PM, Angus wrote:
If memory serves correctly, MTAs like qmail do not read the 'To' and 'Cc'
headers at all. The 'To' and 'Cc' fields are written by the MUA (i.e. the
email client) and constitute part of the message text delivered to the
server by the DATA command. The server doesn't look inside that text at
all. The thing that tells it where to deliver the message is an RCPT
command which is sent as part of the SMTP session.
<snip>
Thank you for that very clear explanation of what's going on behind
the scenes! I hadn't really considered the fact that the mail server
doesn't actually look at the To: and Cc: headers directly. They're all
just RCPT TO: as far as Qmail is concerned.
The first question that comes to my mind is why he's adding the same email
to both 'To' and 'Cc'. That just seems sloppy to me.
Leaving that aside -- maybe he has a reason
I have yet to be offered an actual reason for the behaviour. I'm
thinking laziness. Or, as you suggested, a lack of knowledge.
-- I did a manual telnet session to both a qmail server and to Gmail
to see how they'd handle the case where successive RCPT commands
name the same recipient.
Qmail didn't blink when I told it to deliver to the same recipient three
times, and did indeed deliver three messages. Gmail, on the other hand,
said:
250 2.1.5 OK, duplicate recipients will be consolidated
I haven't found any RFC's at all that specify that this is a required or
even optional behavior. Implementing it does not seem to violate the RFCs
(so long as the server sends a 250 response), but not implementing it
doesn't seem to violate any either.
I couldn't seem to find anything either but I'll freely admit to not
being as familiar with the RFCs as I probably should be.
That's the hazard of being a one-person IT department - when you have
to swap out malfunctioning photocopier coin boxes, troubleshoot
misbehaving receipt printers, maintain Win7 workstations, etc., etc.,
in addition to looking after all of the in-house Windows & Linux
servers, both real & virtual, you tend to know a little bit about a
lot of things but not nearly as much about any one thing as you'd
like and sometimes need. Thank goodness for mailing lists and Google.
I think he's correct that Gmail et all are "smart enough" to consolidate
duplicate addresses, but that this is not a required behavior and Qmail is
perfectly compliant.
Well, at least Qmail isn't "at fault" in the sense of not complying
with any RFCs.
I'm of mixed feelings whether I agree with Gmail et al in "deciding"
to consolidate duplicate recipients. Part of me thinks that it's a
mail server's job to deliver exactly what it's instructed to deliver,
as Qmail currently does, not to second-guess the sender and make its
own decision regarding what to deliver. The rest of me thinks that it
makes sense to consolidate duplicates because mistakes happen and,
after all, who really needs 4 copies of the same message?
I do, however, feel quite strongly that the sending program is very
definitely at fault in addressing the messages redundantly in the
first place and there's no good reason why it shouldn't be fixed. It
manages to correctly send every other automated message just once to
each recipient.
I might be tempted to point out that other developers
are "smart enough" not to address their messages redundantly, but that
might lead to violence.
You read my mind on that one. Now to figure out a way to more
diplomatically imply the same thing.
If, by chance, the developer proves unwilling or unable to fix the
problem, does anyone know if there's any way to configure Qmail to
follow Gmail's example and combine duplicate recipients? I've already
talked to my supervisor about this and confirmed that neither one of
us is going to agree to switch to Exchange or another "smart" server
just to resolve this but HR thinks that it will be too confusing for
staff to receive two copies of the email.
--
IT4SOHO, LLC
33 - 4th Street N, Suite 211
St. Petersburg, FL 33701-3806
CALL TOLL FREE:
877-IT4SOHO
877-484-7646 Phone
727-647-7646 Local
727-490-4394 Fax
We have support plans for QMail!
