I think the complaining about excessive X-headers is overblown. It's not harming anything. Google adds more meat than that nowadays with ARC, multiple DKIM signatures, authentication results, etc. Message headers ain't going to get any smaller, best to learn how to deal with them. Be liberal in what you accept, and all that.
BTW, that customer is doing a good thing by using a subdomain with the ESP. Good from a consumer confidence perspective that it's the real domain. Too many non-techie senders end up using "exmaple-email.com" with their ESP, which isn't great from a consumer confidence perspective. Or even some techie ESP clients want this, because corporate security thinks use of a subdomain is a security risk -- not really looking at the big picture correctly. Not everybody wants to send as @example.com -- some do, some don't. The don'ts sometimes have legitimate reasons, like for example if they want to use the ESP's automation to handle replies, which isn't as easily done when using the top level of the domain. The message initiator should be setting the return path in the SMTP transaction, not in the DATA as a header element, agreed. Regards, Al Iverson On Mon, Apr 30, 2018 at 3:03 PM, Ken O'Driscoll via mailop <[email protected]> wrote: > From what I recall (and I may be wrong) isn't it more along the lines of > only one SHOULD be added? > > And, if you see Envelope From headers in inbound mail streams for which you > are the final destination then you MAY replace/rewrite them. > > Apologies if I have misunderstood what you are saying. > > Ken. > > Sent from my mobile device. > > On 30 Apr 2018 19:02, Michael Peddemors <[email protected]> wrote: > > For the record, and a reminder to others.. > > RFC says that the 'Return-Path', eg EnvelopeFrom should ONLY be added at > the final destination.. > > Emails are being sent with existing Return-Path headers.. meaning they > are added incorrectly for the mailing lists. > > It should be pointed out that a very high number of Invalid Email > accounts were triggered, so you might want to work with the client to > ensure that they are using confirmed double opt-in methods for > collecting sign-ups, and helps stop 'fake sign-up' mailbox DOS attacks.. > > X-Mailer: XyzMailer > X-Xyz-cr: 986 > X-Xyz-cn: 7817 > X-Xyz-bcn: 7751 > X-Xyz-md: 100 > X-Xyz-mg: 32694182 > X-Xyz-et: 111 > X-Xyz-pk: 11086764 > X-Xyz-ct: 837196 > X-Xyz-bct: 813973 > X-PVIQ: 000273-000603-000986-007817-000000 > X-CM-MessageId: 986-7817 > > Kind of a lot of headers, are they all needed? Maybe look at formatting > those into a single header, base64 encoded with the information you need? > > Also, (personal pet peeve).. > > EnvelopeFrom: <[email protected]> > From: "Allegiant" <[email protected]> > > End users understand 'whitelisting' the company that they expect email > from, eg @allegiant.com > > Make it easier for non-techies.. > > Also, when ever sending for a company, encourage them to use SPF records > for their main domain, it helps prevent fake alerts, eg from affiliates, > spammers, or even worse, phishing attacks.. > > (Note, they do have it for e.allegiant.com, but not for allegiant.com) > > Especially for companies that do transactional email, eg confirmation of > ticket purchases, they don't need fake @allegiant.com emails telling > them to look at the attached.. well, you get the drift.. > > BTW, if anyone knows where their transactional email is sent from, let > us know.. > > > -- > "Catch the Magic of Linux..." > ------------------------------------------------------------------------ > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > ------------------------------------------------------------------------ > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and intended > solely for the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > -- al iverson // wombatmail // miami http://www.aliverson.com http://www.spamresource.com _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
