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.


-- 
Best regards,
 Diana Calder                         mailto:dcal...@essexcountylibrary.ca
Automation Technician            (519) 776-5241 x.131
Essex County Library
Essex, ON


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Reply via email to