Re: [mailop] +addressing ... any reason to NOT use it? {dkim-fail}

2021-02-04 Thread Ned Freed via mailop
> I try to use +addressing whenever I sign up for something new. I'd say at > signup it works like 95% of the time. Plenty of forms still don't think > the + is a valid thing to find in an email. I've had 3-4 retailers so far > (LandsEnd was one of them I think) who originally let me setup an acc

Re: [mailop] +addressing ... any reason to NOT use it? {dkim-fail}

2021-02-03 Thread Ned Freed via mailop
> It seems I missed the announcement, but ... > Plus Addressing in Exchange Online | Microsoft > Docs

Re: [mailop] DMARC policy application {dkim-fail}

2020-05-07 Thread Ned Freed via mailop
> On 2020-05-07 11:04 BST, Evan Booyens via mailop wrote: > > Often the hacked account is used to send mail from a spoofed domain. > Why would an email provider permit its users to spoof either the > mail-from or the header-form? Mailing lists work a lot better if you don't mess with the header-f

Re: [mailop] Reasons to add plain text alternative to email? {dkim-fail}

2019-12-10 Thread Ned Freed via mailop
> I want to thank all contributors to this discussion for their feedback. > What I learned from this: > - There are still people that prefer plain text. > - Text alternative may be used by accessibility tools. > - Text alternative should be complete and readable. > - For bulk mail html only should

Re: [mailop] Reasons to add plain text alternative to email?

2019-12-09 Thread Ned Freed via mailop
Generate the plain text alternative if you can. But if you can't, or aren't sure you can, just send the HTML and don't generate the multipart/alternative structure. Far too many multipart/alternative messages are arriving these days with: (a) Blank plain text parts. (b) Plain text parts that say,

Re: [mailop] Respecting MTA-STS {dkim-fail}

2019-10-16 Thread Ned Freed via mailop
> If we want to try and respect MTA-STS, when doing STARTTLS, the sender > needs to send the right information in the TLS SNI (Server Name > Inidication) extension. An MTA-STS-honoring SMTP client expects to > validate the X.509 certificate of the receiving MTA, but that MTA might > be known by a d

Re: [mailop] Gmail - Multiple destination domains per transaction is unsupported {dkim-fail}

2019-09-25 Thread Ned Freed via mailop
> I don't quite get this. Your outbound MTA is grouping separate domains > together into one queue based on MX? There are various ways to do it, but the basic idea is to reuse connections and even transactions based on different domains translating to a common set of MXes, for some defintion of "c

Re: [mailop] HEADER LENGTH as per RFC2822 {dkim-fail}

2019-08-20 Thread Ned Freed via mailop
> In article <75f5a58a-f53f-5222-9e3a-791f21594...@linuxmagic.com> you write: > >>> "An unfolded header field has no length restriction and > >>>therefore may be indeterminately long." > >> > >> You're right. I missed that. > >> > >> But I suspect I'm not the only one who missed it, so I would

Re: [mailop] Gmail & TLS SNI {dkim-fail}

2018-04-16 Thread Ned Freed
> In MX delivery without DNSSEC, if Eve injects an MX record: > gmail.com. IN MX 1 my-spy-agency.example.org. > then using the hostname from DNS means that the client will happily go > talk to my-spy-agency.example.org, using that as the SNI, and validating > against that same domain, then pres

Re: [mailop] question regarding support for international characters {dkim-fail}

2018-04-11 Thread Ned Freed
> Besides, I have a sneaking suspicions that those who take the step of offering > addresses in scripts that have these issues are going to be so busy dealing > with visual similarity, address fakery, and similar issues that we'll be > lucky if they do any sort of normalization at all, let alone d

Re: [mailop] question regarding support for international characters {dkim-fail}

2018-04-11 Thread Ned Freed
>> The Gmail and Hotmail support handles other people's UTF-8 addresses >> in mail but they still don't provide UTF-8 addresses on their own >> systems. > > From what I can tell, Gmail and outlook.com's support is basically "just send > UTF-8", that is, it will send EAI messages without the server

Re: [mailop] question regarding support for international characters {dkim-fail}

2018-04-10 Thread Ned Freed
> In article > > you write: > >-=-=-=-=-=- > >-=-=-=-=-=- > >-=-=-=-=-=- > > > >Hello folks > > > >I've been tasked with finding out what the general consensus is on the > >support in email headers for International characters such as UTF-8 > >Charcacters and including things like accented char

Re: [mailop] Anybody have a pointer to a clued qwet.net mail person?

2017-11-07 Thread Ned Freed
> One of my users is seeing repeated fails to send to hosted mail for nsf.gov > from qwest.net: > first MX: > ... while talking to stn-mtpe-01-03-p.inet.qwest.net.: > >>> DATA > <<< 451 4.3.2 Please try again later > ... Deferred: 451 4.3.2 Please try again later > <<< 503

Re: [mailop] Storing 821 envelope recipients in an 822.Header?

2016-12-07 Thread Ned Freed
> /me is going to go with Envelope-To, as it's going to be the easiest to > explain to users "this is from the envelope at SMTP delivery time, not the To: > or Cc: or anywhere else". FWIW, we chose the closely related X-Envelope-To: for this function many years ago. (At the time best practice was

Re: [mailop] Anyone from AOL on this list?

2016-10-04 Thread Ned Freed
> I just started seeing this: > Site aol.com (152.163.0.68) said after data sent: 421 4.2.1 Dragnet > Timeout > Site aol.com (152.163.0.99) said after data sent: 421 4.2.1 "Service > unavailable. Please try again later." > Anyone else? I've seen the second one of these once. There w