108 Matching Annotations
  1. Feb 2024
  2. Jan 2024
    1. A simple survey should be offered during the unsubscribe process to allow customers to provide feedback about why they are leaving.
    2. Do not send a confirmation email as it can be a violation of CAN-SPAM and you risk further alienating consumers.
  3. Sep 2023
    1. Kamatera is a very good option to run a mail server because They don’t block port 25, so you can send unlimited emails (transactional email and newsletters) without spending money on SMTP relay service. Kamatera doesn’t have any SMTP limits. You can send a million emails per day. The IP address isn’t on any email blacklist. (At least this is true in my case. I chose the Dallas data center.) You definitely don’t want to be listed on the dreaded Microsoft Outlook IP blacklist or the spamrats blacklist. Some blacklists block an entire IP range and you have no way to delist your IP address from this kind of blacklist. You can edit PTR record to improve email deliverability. They allow you to send newsletters to your email subscribers with no hourly limits or daily limits, whatsoever. You can order multiple IP addresses for a single server. This is very useful for folks who need to send a large volume of emails. You can spread email traffic on multiple IP addresses to achieve better email deliverability.
    1. Modoboa is an alternative to those 3 options. It frees you from dependence on email providers and makes accessible to all the creation his own secure email server.
    1. You must include at least the mailto portion of the List-Unsubscribe header, since some services only support this portion (iOS, for example). However, many inbox providers and mail clients honor both methods. To ensure that the greatest number of your recipients have the ability to unsubscribe from your emails, thus protecting your reputation as a sender, we recommend including both mailto and http.
    2. You must include at least the mailto portion of the List-Unsubscribe header, since some services only support this portion (iOS, for example). However, many inbox providers and mail clients honor both methods. To ensure that the greatest number of your recipients have the ability to unsubscribe from your emails, thus protecting your reputation as a sender, we recommend including both mailto and http.
    3. List-Unsubscribe is a small piece of text that can be inserted in the header section of your email. The List-Unsubscribe header will insert an “unsubscribe” button, or link, next to the From address at the top of your email. A recipient can click this link to notify you that they would like to unsubscribe from your emails.
    1. List-unsubscribe can help reduce spam complaints.If subscribers can’t find the unsubscribe link, they may click the spam reporting button instead. This could hurt your email deliverability and sender reputation. To mailbox providers, a spam complaint is a spam complaint, regardless of whether the recipient actually perceived the message as malicious.
    2. Support for list-unsubscribe varies across email clients.
    1. Apparently, Google uses some additional heuristics to decide whether the link should be displayed or not. The List-Unsubscribe header could be abused by spammers to validate that their target got the message, and thus, GMail only shows the unsubscribe link if the source of the message has accumulated sufficient trust.

      Shouldn't it be controllable by the end user, in the same way that they can press a button to show all images if images are blocked by default for security/privacy reasons??

  4. Aug 2023
  5. May 2023
    1. Please can we (a) retain case information from the email address the student uses to set up their account (in case their mailbox is case sensitive), and use that when sending password reset emails, etc., but also (b) when checking credentials for login or setting up an account, treat the email address as non-case-sensitive. The upshot would be if someone registered with Student@City.ac.uk, all emails would go to Student@City.ac.uk, but the student would be able to log in with student@city.ac.uk, and if someone later tried to set up an account with student@city.ac.uk they'd be told that the user already exists.
    2. Although there's an argument for keeping case sensitivity for the local mailbox (as they can be case sensitive, depending on how they're set up, though I haven't come across case sensitivity in university emails), the domain part of the email address is not case sensitive and should not be treated as such. Please can we (a) retain case information from the email address the student uses to set up their account (in case their mailbox is case sensitive), and use that when sending password reset emails, etc., but also (b) when checking credentials for login or setting up an account, treat the email address as non-case-sensitive. The upshot would be if someone registered with Student@City.ac.uk, all emails would go to Student@City.ac.uk, but the student would be able to log in with student@city.ac.uk, and if someone later tried to set up an account with student@city.ac.uk they'd be told that the user already exists.
    1. If you are storing email addresses then you probably should store them in their original case (the recipient at least) to be safe. However, always compare them case-insensitively in order to avoid duplicates.
    1. However, it's difficult to rely on a case-sensitive email address in the real world because many systems (typically ones that have to handle data merging) don't preserve case. Notably systems that use email addresses for user IDs, or any system that has to collate data from multiple sources (CRMs, email broadcast systems, etc) will either normalise case or treat them case-insensitively.
    2. However, for all practical purposes in the modern age, I believe you can consider email addresses to be case insensitive.
    1. a SHOULD is always trumped in RFCs by a MUST. The fact that hosts SHOULD do something means that they might not and I just wanted reassurance that, in reality, the SHOULD is a bit more widely adopted than its definition implies.
    1. While email addresses are only partially case-sensitive, it is generally safe to think of them as case insensitive. All major providers, such as Gmail, Yahoo Mail, Hotmail, and others, treat the local parts of email addresses as case insensitive.
    2. According to RFC 5321, the local part of the email address is case sensitive. This means that, in theory, SoMething@something.com is not the same as something@something.com. However, email providers have the liberty to treat the local parts as both case sensitive and case insensitive.
    1. Are Email Addresses Case Sensitive? Technically, the answer is yes. However, email addresses are typically not case sensitive; if you type your email address into a form and accidentally capitalize one or two letters, it probably won’t prevent the sender from emailing you.
    2. The local part does, in fact, take the case into account, as per RFC 5321. However, Email Service Providers (ESPs) are aware of the potential confusion that could result from allowing upper-case letters.
    1. In short, while it’s technically possible to make the part before @ case sensitive, most popular email servers do not allow that. 
    2. Most big email providers like Gmail, Outlook and even company email address hosted on Google Suite are not case sensitive. Just to avoid any unnecessary confusion. However, in extreme cases, some large companies, implement case sensitivity on their server as some people can often have the same first and last name. But in general, this creates more confusion, than the usability, which is why most standard email providers avoid case sensitivity. 
    1. Either way, at some point almost everyone started treating addresses as case-insensitive.
    2. Despite it being commonplace to “fix up” email addresses by lowercasing them — or, in financial/government contexts, uppercasing them — email addresses are clearly defined as case-sensitive in the only standard that matters.
    1. Since using case insensitivity is so widespread, take their sign up email address and make it lower case. Whenever they try to log in, convert that to lowercase as well, for comparison purposes, when you go to see if the user exists. As far as sign up and sign in go, do a case insensitive comparison. If the person signs up as Steve@example.com, you'll still want to allow them to sign in later with steve@example.com or sTeVE@example.com.
    2. But you should also keep track of the email address that they signed up with in a case sensitive fashion. Any time you send an email to them, be sure to send it with that original casing. This allows the email server to handle it however it feels like it needs to. So even though the person may always be signing in to your site with steve@example.com, if they signed up as Steve@example.com, you'll always send email to Steve@example.com, just to be safe.
    3. The de facto standard is to treat local mailboxes as case insensitive, but the official standard says case matters (though even the official standard mentions the de facto standard).
    1. So yes, the part before the "@" could be case-sensitive, since it is entirely under the control of the host system. In practice though, no widely used mail systems distinguish different addresses based on case.
    2. In short, you are safe to treat email addresses as case-insensitive.
    1. Since the case sensitivity of email addresses can create confusion and delivery problems, most email providers and clients either fix the case if the email address is entered in the wrong case, or they ignore upper-case entries. Not many email services or ISPs enforce case-sensitive email addresses.
  6. Apr 2023
    1. By default SMTP offers very little protection against interception. Traffic may be encrypted between servers but there are no guarantees.

      And how likely is it that the attacker actually owns one of the servers that is a hop on the way from mail sender to mail recipient?? Seems extremely unlikely.

    2. email as a transmission mechanism isn't secure.
  7. Mar 2023
    1. What are transactional emails? Typically any email that is triggered by or sent automatically from your application.
    2. Welcome emails Actionable emails Password resets Receipts Monthly invoices Support requests App error alerts Reminders etc.
    1. for instance, when the recipient’s address is full (a soft bounce: just wait and re-send) or worst, when it’s non-existent (a hard bounce: you need to remove the account from your list)
  8. Feb 2023
    1. Its outlooks rubbish filtering system. They have "AI" rules that look at the sending ip address for reputation. They score you on user reportsand lots of other bits they will not tell you about. Make sure you have SPF, DMARC, DKIM, and sign up for their JMRP and SDNS they will tell you. But it still is a game of cat and mouse. Its a slippery slope and even Microsoft trap their own mail to their own outlook users. PITA, to be honest and luckily we managed to get a mitigation to the issue. However some users in different domains still complain of email going to JUNK. Go figure. I hate having to work on issues with Outlook.com. They themselves send out spam and have the audacity to block well configured SMTP senders. I wish you luck. You will need it.
  9. Dec 2022
    1. Let’s say, you’ve set up the list-unsubscribe header to you email campaign. Check out whether it works by sending an email to a test inbox. For Gmail, you’ll see the unsubscribe option in the header right next to the sender name
    1. Errors-To is deprecated, so mail servers will typically ignore this header - most servers will bounce will to the 'envelope sender'. This is the email address that your mail client sends as part of the connection to the SMTP server (not necessarily the From address - though it typically is the same).
    1. Postmark separates email traffic through Message Streams, meaning that transactional and broadcast traffic never intersects in Postmark, including IP ranges. This is a longstanding best practice for ensuring optimal deliverability. Transactional message streams are for messages that are usually unique and triggered by a user action like a password reset, opted-into weekly digest, or receipts. Transactional streams do not support bulk messages. Broadcast message streams are for bulk messages that sent to multiple recipients at once like announcements, newsletters, or other application email.
    1. The best at transactional email because we never let them mix with bulk messages. You might say that Postmark has serious street cred with inbox providers. To protect the delivery of your transactional emails, it’s crucial to separate them from your bulk or promotional emails. With Message Streams, we’ve built a parallel but completely separate sending infrastructure for these two different types of emails. We don’t let them mix. Ever.
    1. List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://solarmora.com/unsubscribe/example>
    2. Here are some recommended unsubscribe methods: Include a prominent link in the message that takes recipients to a page for unsubscribing. Let recipients review the individual mailing lists they’re subscribed to. Let them unsubscribe from lists individually, or all lists at once. Automatically unsubscribe recipients who have multiple bounced messages. Periodically send a confirmation message to recipients to make sure they still want to get your messages.
    3. Let recipients easily unsubscribe Always give recipients a way to unsubscribe from your messages. Make unsubscribing easy. Letting people opt out of your messages can improve message open rates, click-through rates, and sending efficiency.
    4. Make sure recipients can easily subscribe
    1. Many mail systems allow recipients to report mail as spam or junk, and mail streams from senders whose mail is often reported as junk tend to have poor deliverability. Hence, the mailers want to make it as easy as possible for recipients to unsubscribe; if an unsubscription process is too difficult, the recipient's alternative is to report mail from the sender as junk until the mail no longer appears in the recipient's inbox.
    2. Operators of recipient mail systems are aware that their users do not make a clear distinction between unsubscription and junk.
  10. Nov 2022
    1. You can definitely set the Return-Path header as a sender. But yes, some receivers might rewrite it (But not always ), or depending on who you're sending through, it might be re-written by them. For instance when using MailGun to send bulk email you have to do things just right in order to set a Return-Path that will be preserved. I know this contradicts the RFC you cite, but it's in practice true.
    2. Return-Path header is written by the receiving server, not by the sending server. And as per the RFC 5321, it is the same as the address supplied in MAIL FROM command.
  11. Oct 2022
    1. eMail hat tatsächlich nicht mehr den Stellenwert wie früher - als es wirklich noch wie schnellerer Briefverkehr genutzt wurde und deutlich förmlicher und verbindlicher war. Heute sehe ich das auch die Kundschaft eMail schon auf SMS-Niveau benutzt, was mir in der Seele wehtut, weil das eine völlig unwürdige Form der Kommunikation ist.
    1. Importante fornecer um e-mail válido para a solicitação da nota fiscal.
  12. Sep 2022
    1. Snail mail can be too slow, and email isn't secure. So that leaves us with the decades-old, but still reliable, fax.

      email is secure enough. Why do people keep perpetuating this myth?

  13. Feb 2022
    1. Hence an email address/mailbox/addr-spec is "local-part@domain"; "local-part" is composed of one or more of 'word' and periods; "word" can be an "atom" which can include anything except "specials", control characters or blank/space; and specials (the *only* printable ASCII characters [other than space, if you call space "printable"] *excluded* from being a valid "local-part") are: ()<>@,;:\".[] Therefore by the official standard for email on the internet, the plus sign is as much a legal character in the local-part of an email address as "a" or "_" or "-" or most any other symbol you see on the main part of a standard keyboard.
    2. There's a common design flaw on many many websites that require an email address to register; most recently I came across this bug on CNet's download.com site: for some reason they don't accept me when I try to register an email address containing a "+", and they then send me back saying my address is invalid. It isn't!
    3. "+" is a completely valid character in an email address; as defined by the internet messaging standard published in 1982(!) RFC 822 (page 8 & 9)... Any website claiming anything else is wrong by definition, plus they are prohibiting me and many fellow anti-spam activists from tracking where inbound spam comes from:
  14. Oct 2021
  15. Aug 2021
  16. May 2021
  17. Mar 2021
    1. Ownership is the critical point here. Ownership in email in the same way we own a paperback: We recognize that we (largely) control the email subscriber lists, they are portable, they are not governed by unknowable algorithmic timelines.3 And this isn’t ownership yoked to a company or piece of software operating on quarterly horizon, or even multi-year horizon, but rather to a half-century horizon. Email is a (the only?) networked publishing technology with both widespread, near universal adoption,4 and history. It is, as they say, proven.

      This is very IndieWeb in flavor.

      It reminds me of Stanley Meyer who would read newspapers and magazines every day and cut out articles which he put into envelopes for his friends and children and mailed out every couple of weeks. Essentially his own newsletter, but by snail mail.

  18. Feb 2021
    1. URI::MailTo::EMAIL_REGEXP

      First time I've seen someone create a validator by simply matching against URI::MailTo::EMAIL_REGEXP from std lib. More often you see people copying and pasting some really long regex that they don't understand and is probably not loose enough. It's much better, though, to simply reuse a standard one from a library — by reference, rather than copying and pasting!!

    1. Direct Express Dispute Processing PO Box 540190 Omaha, NE 68154-0190
    2. i2c, Inc.                  ATTN: Rob Seiler                  100 Redwood Shores Parkway                  Suite 100                  Redwood City, CA 94065
  19. Dec 2020
    1. 2.3.1. Mail Objects SMTP transports a mail object. A mail object contains an envelope and content. The SMTP envelope is sent as a series of SMTP protocol units (described in Section 3). It consists of an originator address (to Klensin Standards Track [Page 11] RFC 5321 SMTP October 2008 which error reports should be directed), one or more recipient addresses, and optional protocol extension material

      The SMTP envelope is sent as a series of SMTP protocol units (described in Section 3). It consists of

      • an originator address (to which error reports should be directed),

      MAIL FROM that refers to the originator (a.k.a., reverse path, backward-pointing address) of the request

      • one or more recipient addresses,

      Multiple RCPT TO for each "to:" rfc822 message header in the mail data (see annotation)

      • and optional protocol extension material.

      DATA (see below)


      (See also envelope-vs-mail tags.)

    2. When the RFC 822 format ([28], [4]) is being used, the mail data include the header fields such as those named Date, Subject, To, Cc, and From.

      This just answered my question regarding the quote from "Postfix: The Definitive Guide":

      ENVELOPE ADDRESSES AND MESSAGE HEADERS A common source of confusion for email users is the fact that the To: address in email message headers has nothing to do with where a message is actually delivered. The envelope address controls message delivery. In practice, when you compose a message and provide your MUA with a To: address, your MUA uses that same address as the envelope destination address, but this is not required nor is it always the case. From the MTA’s point of view, message headers are part of the content of an email message. The delivery of a message is determined by the addresses specified during the SMTP conversation. These addresses are the envelope addresses , and they are the only thing that determine where messages go. See Section 2.2.8 later in the chapter for an explanation of the SMTP protocol.

      Mailing lists and spam are common examples of when the envelope destination address differs from the To: address of the message headers.

      Also an answer to this question.

    3. An SMTP-capable host SHOULD support both the alias and the list models of address expansion for multiple delivery. When a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person or other entity who administers the list. However, in this case, the message header section (RFC 5322 [4]) MUST be left unchanged; in particular, the "From" field of the header section is unaffected.

      Another section that serves well to understand the difference between email data and SMTP envelope.

    4. To expand an alias, the recipient mailer simply replaces the pseudo- mailbox address in the envelope with each of the expanded addresses in turn; the rest of the envelope and the message body are left unchanged. The message is then delivered or forwarded to each expanded address.

      This annotation explains what this paragraph means and dispels my confusion regarding how 3mails with multiple recipients will get processed (also, SMTP envelope vs mail data).

      MS Outlook's "distribution list" is the same as an rfc5321 alias.

    5. The return (backward-pointing) address in the envelope is changed so that all error messages generated by the final deliveries will be returned to a list administrator, not to the message originator, who generally has no control over the contents of the list and will typically find error messages annoying.
      1. This the only difference between an SMTP alias and list; expanding recipients to RCPT commands is the same.
      1. Another great example to highlight the difference between SMTP envelope and mail data: the envelope's MAIL FROM (see annotation) is different from to the mail data's rfc822 From:.
    6. If the Klensin Standards Track [Page 19] RFC 5321 SMTP October 2008 recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as "no such user - " and the mailbox name (other circumstances and reply codes are possible).

      Will the entire transaction be canceled? "Transaction" in the name of this a section implies yes, but what if all the recipients are valid?

      See replies below but the answer is no; an RCPT command is specified for each recipient in the mail data, these RCPT commands will be evaluated in sequence,, and any SMTP (error) notifications will be sent to the address in the MAIL FROM command (which is not necessarily the same as the mail data's From: header).

    7. the reverse-path (originator) address specification command (MAIL)

      Sometimes "reverse path" or "originator" address is also referred to "backward-pointing" address (and those instances also refer to the MAIL command mostly).

  20. Jul 2020
  21. Jun 2020
    1. dark pattern design will ensure the opt out — if there is one — will be near invisible; Greyscale text on a grey background is the usual choice.

      The often used method on promotional emails and/or advertising website.

  22. Mar 2019
    1. Carson Farmer noted that GMAIL is fundamentally a better user experience because individuals didn’t need to run their own protocols or set up their own servers.

      If so, why then not use ProtonMail that does not serve ads, abuse your data, and gives you the option for built-in e-mail encryption?

  23. Apr 2018
    1. Use the built-in compose-mail to send mails.

      Maybe no Check and see if this will open external mail program

  24. Sep 2015
  25. Feb 2015