Re: [qmailtoaster] Qmail's handling of same account in both TO: and CC: headers
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
Re: [qmailtoaster] Qmail's handling of same account in both TO: and CC: headers
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
[qmailtoaster] Qmail's handling of same account in both TO: and CC: headers
We are implementing a new piece of software to handle vacation requests. The program connects directly to our Qmail server's SMTP - no other mail servers are involved. Said software sends an email to the requester and their supervisor when the supervisor okays the vacation request. The requester currently receives the same email twice because the program puts the requester's email address in both the TO: and the CC: headers. The software developer and I are having a bit of a discussion regarding this. My position is that Qmail is doing its job correctly by delivering the email exactly as it is addressed and the problem lies in his program which is clearly incorrect in the way that it addresses the message. The developer's position is that our email server is at fault. He proved this by sending an email with his address in it 5 times (once in TO: and 4x in CC:). He claims that Qmail is at fault because other email servers (like Exchange and Gmail) are, and I quote, smart enough to recognize that all copies are for one person therefore instead of 5 emails only one copy is in my inbox. Because of this, getting him to fix his broken program is becoming somewhat of an issue. Just to confirm here - anybody have a handy RFC to prove that Qmail is actually doing what it should by delivering email as addressed and the other mail servers are actually behaving in a non-standard way by deciding that the emails are all the same and only delivering one copy? Or am I wrong and Qmail is indeed in the wrong by delivering exactly what the headers tell it to? -- 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
Re: [qmailtoaster] Qmail's handling of same account in both TO: and CC: headers
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. So if your developer is obsessing over the content of the 'To' and 'Cc' fields, it suggests that he doesn't know as much about email as he thinks he does. Or, more likely, that he's using a library that abstracts away the details. He's doing something like: message = new Message(); message.add_to_recipient(someone@somewhere) message.add_cc_recipient(someone@somewhere) message.add_cc_recipient(someones-boss@somewhere) and the library is configured to send an RCPT command for every address in the 'to' and 'cc' slots of the message object, so it's doing: RCPT TO: someone@somewhere RCPT TO: someone@somewhere RCPT TO: someones-boss@somewhere 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 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 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. 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. Angus Diana Calder wrote: We are implementing a new piece of software to handle vacation requests. The program connects directly to our Qmail server's SMTP - no other mail servers are involved. Said software sends an email to the requester and their supervisor when the supervisor okays the vacation request. The requester currently receives the same email twice because the program puts the requester's email address in both the TO: and the CC: headers. The software developer and I are having a bit of a discussion regarding this. My position is that Qmail is doing its job correctly by delivering the email exactly as it is addressed and the problem lies in his program which is clearly incorrect in the way that it addresses the message. The developer's position is that our email server is at fault. He proved this by sending an email with his address in it 5 times (once in TO: and 4x in CC:). He claims that Qmail is at fault because other email servers (like Exchange and Gmail) are, and I quote, smart enough to recognize that all copies are for one person therefore instead of 5 emails only one copy is in my inbox. Because of this, getting him to fix his broken program is becoming somewhat of an issue. Just to confirm here - anybody have a handy RFC to prove that Qmail is actually doing what it should by delivering email as addressed and the other mail servers are actually behaving in a non-standard way by deciding that the emails are all the same and only delivering one copy? Or am I wrong and Qmail is indeed in the wrong by delivering exactly what the headers tell it to? -- 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 -- - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
