If a contact ever reaches out and is no longer receiving messages because they accidentally marked one of your campaigns as spam, you can reach out to Product Support. We can remove them from the suppression list for you. 

For compliance reasons, you will not be able to see contacts who submit spam complaints in your exclusion list.  We do not offer the ability to export a list of spam complaints from FBLs at the moment. This is also for compliance. 

Information is blocked from going outside the organization when data is not supposed to leave the tenant boundary for compliance purposes (for example, in U.S. Government organizations: Microsoft 365 GCC, GCC High, and DoD). Reporting a message or file to Microsoft from one of these organizations will have the following message in the result details: Further investigation needed. Your tenant does not allow data to leave the environment, so we could not find anything with an initial scan. You'll need to contact Microsoft support to have this item reviewed.

Submit false positives (good email that was blocked or sent to junk folder) and false negatives (unwanted email or phish that was delivered to the inbox)

The target of the POST action is the same as the one in the GET action for a manual unsubscription, so this is intended to allow the same server code to handle both.

The mail sender MUST NOT return an HTTPS redirect, since redirected POST actions have historically not worked reliably, and many browsers have turned redirected HTTP POSTs into GETs.

This specification provides a way for recipient systems to notify the mailer automatically, using only information within the mail message, and without prearrangement.

This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field.

This article was previously called Bulk sender guidelines.

Also, make sure a user does not need to enter credentials or select a checkbox to complete the unsubscription process.

With the http method, behind the list-unsubscribe header, there is a URL leading to a web page for opting out. When a user clicks the unsubscribe link, a landing page opens, and the user is asked to confirm unsubscription.

Imagine what happens when subscribers change activities, interests, or focus. As a result, they may no longer be interested in the products and services you offer. The emails they receive from you are now either ‘marked as read’ in their inbox or simply ignored. They neither click the spam reporting button nor attempt to find the unsubscribe link in the text. They are no longer your customers, but you don’t know it.

Let’s say the recipient is considering unsubscribing. He or she may be too busy to search through the email to find the unsubscribe link, so he or she just clicks “Report as SPAM” to stop the emails from coming. This is the last thing any marketer wants to see happen. It negatively impacts sender reputation, requiring extra work to improve email deliverability. With the list-unsubscribe header, you will avoid getting into this kind of trouble in the first place.

Certain email servers, Yahoo especially, throttle deliveries when multiple inbound is detected from the same IP. When this happens, Mailgun sends a "temporary" severity bounce. Mailgun will continue to retry over a period of time. If it can't deliver after 8 hours. The email will permanently fail with severity: permanent and reason: old.

Just to add that there is also reason: old. This happens when email cannot be delivered after 8 hours. It should still be treated as a non permanent bounce though.

Adding a condition to ensure that a contact is marked as bounced only if the reason is one of the above, should hopefully resolve this issue.

I did some further digging and found that there is a reason property that can be used to determine whether Mailgun added an email address to its bounce suppression list:

...but even repeated soft bounces is a message level event, not one that means there will never be an opportunity to deliver to this address again. Hence Mailgun itself not adding this to their permanent uppression list..but that implies, right, that they will send to the permanent failure hook in this case?

From that quote above, it is clear Mailgun recognise this issue themselves (the possibility of one-off soft bounces for a variety of reasons) and therefore do not add these contacts to their permanent bounce list - unless its a true hard bounce. But they are rightly still alerting that the message in question has permanently failed to be delivered on this occasion.

Mailgun, with its permanent failure webhook, is sending a message about a permanent failure of that specific message - it is Campaign that is then making a decision to translate this message, about just that one message, into a permanently bounced (suppressed) contact, and blocking all future emails to that contact - based on, what is clearly quite possibly just a temporary failure. It's really the distinction between a single message level (temporary) problem and a (permanent) contact level problem that is being lost with Campaign's current approach.

but that before marking the contact as a bounced, Campaign should double check it was really a hard bounce that would affect future deliverability.

some are legit bounces (people who typed emails wrongly etc) - but some are 'too old' which is a generic deliverability type message (according to Mailgun)

This becomes, then, a thorny problem - these perfectly valid emails, that are affected by this temporary issue - are marked as permanently bounced in Campaign...when they really shouldn't be given this bigger picture.

But these are not permanent failures - they ARE permanent for that message of course

his is not wonderfully clear/great form Mailgun's end (as they are effectively translating a temporary delivery issues into a message about a permanent contact failure) - but the net effect is pretty broken handling of temporary bounces against contacts, which just creates inaccuracies and a bit of a mess.

but really anyone using Mailgun is going to want this, aren't they?

Mailgun, like all of these services at the more affordable levels, uses shared IPs for sending the mail. Unfortunately, as I have found over the last 3 or 4 years with them, it is not uncommon that one of their IPs gets blacklisted by SpamCop and similar services due to some other user of that IP being 'noisy' as Mailgun put it.

Yes you could disable the Mailgun webhooks altogether as Mailgun will never allow sending to hard bounced email addresses.

This then leads to the refactoring of creating your own method to output text that accounts for the supplied or defined option:

Hacker. Emacs fanatic. Lover of parentheses. Firebrand. Just another programmer with too many opinions. I’m not the best, but I’m pretty good.

2 • 3 = 6

Ideally we could use Unicode, 3 2 1 ~ 3 2 1 ≃

Mash duplicates any sub-Hashes that you add to it and wraps them in a Mash. This allows for infinite chaining of nested Hashes within a Mash without modifying the object(s) that are passed into the Mash. When you subclass Mash, the subclass wraps any sub-Hashes in its own class. This preserves any extensions that you mixed into the Mash subclass and allows them to work within the sub-Hashes, in addition to the main containing Mash.

eierlegende Wollmilchsau

foo = Foo.new(bar: 'baz') #=> {:bar=>"baz"} qux = { **foo, quux: 'corge' } #=> {:bar=> "baz", :quux=>"corge"} qux.is_a?(Foo) #=> true

by using symbols as keys, you will be able to use the implicit conversion of a Mash via the #to_hash method to destructure (or splat) the contents of a Mash out to a block

by using symbols as keys, you will be able to use the implicit conversion of a Mash via the #to_hash method to destructure (or splat) the contents of a Mash out to a block

It can be useful to use with keywords argument, which required symbol keys.

This extension still allows indifferent access, but keeps the form of the keys to eliminate confusion when you're not expecting the keys to change.

Since Mash is conceived to provide psuedo-object functionality, handling keys which cannot represent a method call falls outside its scope of value.

Hashie does not have built-in support for coercing boolean values, since Ruby does not have a built-in boolean type or standard method for coercing to a boolean. You can coerce to booleans using a custom proc.

Note: The ? method will return false if a key has been set to false or nil. In order to check if a key has been set at all, use the mash.key?('some_key') method instead.

Mash is an extended Hash that gives simple pseudo-object functionality that can be built from hashes and easily extended. It is intended to give the user easier access to the objects within the Mash through a property-like syntax, while still retaining all Hash functionality.

user.deep_fetch :groups, 1, :name

Though this is a hash extension, it conveniently allows for arrays to be present in the nested structure. This feature makes the extension particularly useful for working with JSON API responses.

Value coercions, on the other hand, will coerce values based on the type of the value being inserted. This is useful if you are trying to build a Hash-like class that is self-propagating.

In our system, events are generated by physical hosts and follow different routes to the event storage. Therefore, the order in which they appear in the storage and become retrievable - via the events API - does not always correspond to the order in which they occur. Consequently, this system behavior makes straight forward implementation of event polling miss some events. The page of most recent events returned by the events API may not contain all the events that occurred at that time because some of them could still be on their way to the storage engine. When the events arrive and are eventually indexed, they are inserted into the already retrieved pages which could result in the event being missed if the pages are accessed too early (i.e. before all events for the page are available). To ensure that all your events are retrieved and accounted for please implement polling the following way:

A SimpleDelegator instance can take advantage of the fact that SimpleDelegator is a subclass of Delegator to call super to have methods called on the object being delegated to. class SuperArray < SimpleDelegator def [](*args) super + 1 end end SuperArray.new([1])[0] #=> 2

Set the endpoint to Mailgun's Postbin. A Postbin is a web service that allows you to post data, which is then displayed through a browser. This allows you to quickly determine what is actually being transmitted to Mailgun's API.

PostBin, a simple web service for testing and logging of the receival of WebHooks (HTTP POST requests).

The web API is now the most common meaning of the term API

You can access Events through a few interfaces: Webhooks (we POST data to your URL). The Events API (you GET data through the API). The Logs tab of the Control Panel (GUI).

{ "folders": [ { "path": "apps/api" }, { "path": "apps/crawler" }, { "name": "root", "path": "." } ], "settings": {} }

Bash maintains an internal hash of previously found executables in your path. In this case, it has details that at one time there was an executable at /usr/bin/siege, and reuses that path to avoid having to search again. You need to tell bash to manually rehash the path for siege like so: hash siege You can also clear all hashed locations: hash -r

Remember there are two kinds of variable. Internal Variables and Environment Variables. PATH should be an environment variable.

All shells should tell you that your path is the same thing with BOTH of the two commands: # The PATH variable echo "$PATH" # The PATH environment variable env | /bin/grep PATH

This was originally disallowed because #5907 was opened asking for different behavior in this situation that we didn't want to allow, and so we decided to make it a compiler error rather than have confusing behavior in that situation.

In v3, svelte-preprocess was able to type-check Svelte components. However, giving the specifics of the structure of a Svelte component and how the script and markup contents are related, type-checking was sub-optimal. In v4, your TypeScript code will only be transpiled into JavaScript, with no type-checking whatsoever. We're moving the responsibility of type-checking to tools better fit to handle it, such as svelte-check, for CLI and CI usage, and the VS Code extension, for type-checking while developing.

Not trying to be presumptuous, but thought this proposal would be best served with a PR.

Undecided yet what bundler to use? We suggest using SvelteKit, or Vite with vite-plugin-svelte.

The console needs to be readable in development and to provide the best DX I have to design my libraries in ways that prevent these warnings. This results in design decisions that are detrimental to functionality and/or code readability/simplicity.

You're likely not using "type": "module" in your package.json, so import statements don't work in svelte.config.js. You have three ways to fix this: Use require() instead (also see https://github.com/sveltejs/language-tools/blob/master/docs/preprocessors/in-general.md#generic-setup) Rename svelte.config.js to svelte.config.mjs Set "type": "module" in your package.json (may break other scripts)

Use a :global rule to only expose parts of the stylesheet:

it is not part of Svelte but it is part of Svelte Preprocess github.com/sveltejs/svelte-preprocess#global-style

Warning: This ignores the user's keyboard layout, so that if the user presses the key at the "Y" position in a QWERTY keyboard layout (near the middle of the row above the home row), this will always return "KeyY", even if the user has a QWERTZ keyboard (which would mean the user expects a "Z" and all the other properties would indicate a "Z") or a Dvorak keyboard layout (where the user would expect an "F"). If you want to display the correct keystrokes to the user, you can use Keyboard.getLayoutMap().

I'm rather concerned about adding svelte.config.js support to things that already have well established mechanisms for configuration.

It would probably be worth mentioning this explicitly in the README: "Configuration of the language server happens over the LSP protocol by passing a configuration object; your LSP client should have a way of setting the configuration object for a server. Here is a link to the spec for the configuration that is supported [...]"

So when configuring Capybara, I'm using ignore_default_browser_options, and only re-use this DEFAULT_OPTIONS and exclude the key I don't want Capybara::Cuprite::Driver.new( app, { ignore_default_browser_options: true, window_size: [1200, 800], browser_options: { 'no-sandbox': nil }.merge(Ferrum::Browser::Options::Chrome::DEFAULT_OPTIONS.except( "disable-features", "disable-translate", "headless" )), headless: false, } )

If you are going to crawl sites you better use Ferrum or Vessel because you crawl, not test.

As simple as Puppeteer, though even simpler.

The thing is Chrome doesn't provide details about such resources.

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.

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.

This buildpack installs shims that always add --headless, --disable-gpu, --no-sandbox, and --remote-debugging-port=9222 to any google-chrome command as you'll have trouble running Chrome on a Heroku dyno otherwise.

Do you know about lacolhost.com? as in, do something like blerg.lacolhost.com:3000/ as your url and it'll resolve to localhost:3000, which is where your tests are running.

I have DNS settings in my hosts file that are what resolve the visits to localhost, but also preserve the subdomain in the request (this latter point is important because Rails path helpers care which subdomain is being requested)

I've developed additional perspective on this issue - I have DNS settings in my hosts file that are what resolve the visits to localhost, but also preserve the subdomain in the request (this latter point is important because Rails path helpers care which subdomain is being requested) To sum up the scope of the problem as it stands now - I need a way within Heroku/Capybara system tests to both route requests to localhost, but also maintain the subdomain information of the request. I've been able to accomplish one or the other, but haven't found a configuration that provides both yet.

subject { described_class.do_something }

I have been doing different things w/ Ruby for a couple of years now and the only bad thing I can say about it is that it makes programming in other languages feel awfully burdensome. = )

I would like to understand this design then. In my experience it has only served to limit what I can achieve, and gained me no additional benefit.

Benoit Daloze of TruffleRuby points out that this is all much easier to read if you define your Ruby internals in Ruby, like they do. He's not wrong.

first we're looking for the "main" object. The word "main" is used in lots of places in Ruby, so that will be hard to track down. How else can we search?Luckily, we know that if you print out that object, it says "main". Which means we should be able to find the string "main", quotes and all, in C.

Refresh tokens are bearer tokens. It's impossible for the authorization server to know who is legitimate or malicious when receiving a new access token request. We could then treat all users as potentially malicious.

How could we handle a situation where there is a race condition between a legitimate user and a malicious one?

There are also many reasons refresh tokens may expire prior to any expected lifetime of them as well.

You might notice that the “expires_in” property refers to the access token, not the refresh token. The expiration time of the refresh token is intentionally never communicated to the client. This is because the client has no actionable steps it can take even if it were able to know when the refresh token would expire.

But what about a Refresh Token flow? When using a refresh token, confidential clients also have to authenticate. Public clients, such as browser-based applications, do not authenticate during the Refresh Token flow. So in a typical frontend application, refresh tokens issued to frontend web applications are bearer tokens.   In practice, this means that if an attacker manages to steal a refresh token from a frontend application, they can use that token in a Refresh Token flow. To counter such attacks, the OAuth 2.0 specifications mandate that browser-based applications apply a security measure known as refresh token rotation.

you can use a Backend for Frontend (BFF)

Grant Types

For example, if I make an application (Client) that allows a user (Resource Owner) to make notes and save them as a repo in their GitHub account (Resource Server), then my application will need to access their GitHub data. It's not secure for the user to directly supply their GitHub username and password to my application and grant full access to the entire account. Instead, using OAuth 2.0, they can go through an authorization flow that will grant limited access to some resources based on a scope, and I will never have access to any other data or their password.

Proof of Key Code Exchange is an OAuth2 extension that recently been adopted as the standard for both OAuth 2.1 and IndieAuth, and provides additional security for attacks on the Authorization Code flow.

This is an effective, dynamic stand-in for a fixed secret.

Here’s what this flow looks like:

Until now, we had a lot of code. Although we were using a plugin to help with boilerplate code, ready endpoints, and webpages for sign in/sign up management, a lot of adaptations were necessary. This is when Doorkeeper comes to the rescue. It is not only an OAuth 2 provider for Rails but also a full OAuth 2 suite for Ruby and related frameworks (Sinatra, Devise, MongoDB, support for JWT, and more).

The process used to create an OAuth wrapper client is very simple.

This document defines how a JWT Bearer Token can be used to request an access token when a client wishes to utilize an existing trust relationship, expressed through the semantics of the JWT, without a direct user-approval step at the authorization server.

Can I try the endpoints before I implement my application?

If the Client is a Single-Page App (SPA), an application running in a browser using a scripting language like JavaScript, there are two grant options: the Authorization Code Flow with Proof Key for Code Exchange (PKCE) and the Implicit Flow with Form Post. For most cases, we recommend using the Authorization Code Flow with PKCE because the Access Token is not exposed on the client side, and this flow can return Refresh Tokens.

Is the Client absolutely trusted with user credentials?

Which OAuth 2.0 Flow Should I Use?

If the Client is a regular web app executing on a server, then the Authorization Code Flow is the flow you should use. Using this the Client can retrieve an Access Token and, optionally, a Refresh Token.

The first decision point is about whether the party that requires access to resources is a machine. In the case of machine-to-machine authorization, the Client is also the Resource Owner, so no end-user authorization is needed.

you will need to add a few more braces

The Console now supports redeclaration of const variables across separate REPL scripts (such as when you run a statement in the Console), in addition to the existing let and class redeclarations. This support allows you to experiment with different declarations for const variables without refreshing the page. Previously, DevTools threw a syntax error if you redeclared a const binding.

The Console now supports redeclaration of const statement, in addition to the existing let and class redeclarations. The inability to redeclare was a common annoyance for web developers who use the Console to experiment with new JavaScript code.

Note that strings here are encoded as UTF-8, unlike the usual JavaScript UTF-16 strings.

A File object is a specific kind of Blob, and can be used in any context that a Blob can.

binary string (i.e., a string in which each character in the string is treated as a byte of binary data)

convert the string such that each 16-bit unit occupies only one byte

The btoa() function takes a JavaScript string as a parameter. In JavaScript strings are represented using the UTF-16 character encoding: in this encoding, strings are represented as a sequence of 16-bit (2 byte) units. Every ASCII character fits into the first byte of one of these units, but many other characters don't. Base64, by design, expects binary data as its input. In terms of JavaScript strings, this means strings in which each character occupies only one byte. So if you pass a string into btoa() containing characters that occupy more than one byte, you will get an error, because this is not considered binary data:

If you need to encode Unicode text as ASCII using btoa(), one option is to convert the string such that each 16-bit unit occupies only one byte.

Honestly, at this point, I don't even know what tools I'm using, and which is responsible for what feature. Diving into the code of capybara and cucumber yields hundreds of lines of metaprogramming magic that somehow accretes into a testing framework. It's really making me loathe TDD despite my previous youthful enthusiasm.

Wow, the man himself.

Your tests then should also work correctly with transactional testing (and no need for database cleaner)

To setup it

Please refer to the help center for possible explanations why a question might be removed.

This question was removed from Stack Overflow for reasons of moderation.

In general, I've found Selenium to be unreliable and not deterministic as laid out here although I still don't entirely know why.

session = ActionDispatch::Integration::Session.new(Rails.application) response = session.post("/mypath", my_params: "go_here")

As has been stated elsewhere, in a Capybara test you typically want to do POSTs by submitting a form just like the user would.

I used the above to test what happens to the user if a POST happens in another session (via WebSockets), so a form wouldn't cut it.

So far for the obligatory warning. I get the point, I even agree with the argument, but I still want to send a POST request. Maybe you are testing an API without a user interface or you are writing router tests? Is it really impossible to simulate a POST request with Capybara? Nah, of course not!

The Capybara Ruby gem doesn’t support POST requests, the built-in visit method always uses GET. This is by design and with good reason: Capybara is built for acceptance testing and a user would never ask to ‘post’ parameter X and Y to the application. There will always be some kind of interface, a form for example. It makes more sense to simulate what the visitor would really do

“Have you brought your time sheet up to date yet?”

module InjectSession include Warden::Test::Helpers def inject_session(hash) Warden.on_next_request do |proxy| hash.each do |key, value| proxy.raw_session[key] = value end end end end

This site is making use of some basic analytics cookies so I can hopefully learn something from of the metrics. By using the site you are totally fine with that.

And with diagrams as text close to the code chances are they will be kept to up to date (and created to begin with…).

There IS a super nice Visual Studio Code plugin for it but it still comes with the environment pre-reqs AS well as the cumbersome pressing of Alt-D (or was it Ctrl-D??) to get the preview. For other IDE’s I bet there are similar plugins leaving the same nasty taste of dissatisfaction… and the pollution of your environment.

You may want to change the controllers to your custom controllers with: Rails.application.routes.draw do use_doorkeeper do # it accepts :authorizations, :tokens, :token_info, :applications and :authorized_applications controllers :applications => 'custom_applications' end end

If you want to extend the default behaviour, just inherit from Doorkeeper::ApplicationsController. For example: class CustomApplicationsController < Doorkeeper::ApplicationsController end

This is ugly by design, as an inducement to test properties instead of specifics.

So transcriptor aims to do less, and impose the bare minimum of cognitive load needed to convert a REPL interaction into a test. The entire API is four functions:

Testing frameworks often introduce their own abstractions for e.g. evaluation order, data validation, reporting, scope, code reuse, state, and lifecycle. In my experience, these abstractions are always needlessly different from (and inferior to) related abstractions provided by the language itself.