You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refuse AUTHENTICATE for cleartext connections, configurable per authenticator
Using capabilities information
The client should track whenever it is knowingly violating capabilitied, either server reported or client enabled. At the very least, this should include checking capabilities before sending specific commands or command arguments.
Client-enabled capabilties
There will be no API to work around client.enable(capability). Users who are determined to evade this limitation can figure out how cheat with client.instance_variable_set(...).
Server reported capabilities
The server capabilties cache will always be kept up-to-date when capabilities are checked. If the server hasn't sent its capabilities unsolicited, the client will request capabilties whenever capabilities are checked.
If the capabilities check fails:
For new commands or new arguments to existing commands.
A CapabilityError will be raised without issuing any command to the server,
Where there is a security risk.
A CapabilityError will be raised without issuing any command to the server,
This is backwards incompatible!
For other existing commands with existing command arguments.
A warning will be printed to $stderr but the command will still be sent
In some future version of Net::IMAP (perhaps the version released with ruby 3.2 or 3.3), the default for existing commands should change to match the behavior for new commands.
Configuration
To opt-out of the new behavior or to opt-in to more strict behavior:
Net::IMAP#enforce_capabilities=
nil -- Uses the current default behavior, which can change in future releases.
true -- Always raise an exception for any failed capabilities checks. Never knowingly sends unsupported commands or command arguments to the server.
:warn -- Prints a warning to $stderr for non-security-related capabilities, regardless of the command or the current Net::IMAP default. Still raises for security-related capabilities checks.
false -- Restores old default behavior: client doesn't care about server capabilities. Still warns for security-related capabilities checks.
def []: (CapabilityError, Net::IMAP) -> (nil | true | false | :warn), eg. a Proc. May change security-related capabilities handling.. The command, command args, required capabilities, etc will all be available on CapabilityError.
Shorthand for Net::IMAP.new(...).tap {|client| client.enforce_capabilities = cfg }
Net::IMAP#cmdname(..., enforce_capabilities: cfg)
#cmdname represents any command which might check server capability.
This kwarg also changes security-related capabilities handling for #starttls, #authenticate, #login.
opting out of security errors
enforce_capabilities: false will still raise a warning for security related violations. These warnings can only be disabled with a proc.
client.authenticate("PLAIN",username,password,enforce_capabilities: false)# $stderr << "warning: Ignoring server capability \"AUTH=PLAIN\"" unless capability?("AUTH=PLAIN")# The server might respond with a tagged `NO` => `NoResponseError`client.login(username,password,enforce_capabilities: false)# $stderr << "warning: Ignoring server capability \"LOGINDISABLED\"" if capability?("LOGINDISABLED")# The server might respond with a tagged `NO` => `NoResponseError`# Always ignore server capabilities. Please don't do this!client=Net::IMAP.new(...,enforce_capabilities: ->_{false})client.enforce_capabilities=->_{false}
Allow fine-grained configuration with a Proc
The arguments will be a CapabilityError exception (which can be raised) and the Net::IMAP client object (in case the proc is shared between multiple clients). CapabilityError should have at least one sub-class, SecurityCapabilityError, to represent LOGINDISABLED, AUTH=, STARTTLS capabilities, etc. CapabilityError and its subclasses should allow pattern matching via #deconstruct and/or #deconstruct_keys
This could be used to:
add support for capabilities which haven't been added to net-imap yet
log unexpectedly missing security related capabilities errors.
log all capabilities errors.
client.enforce_capabilities=procdo |error|
caseerrorinAuthCapabilityError{sasl_mechanism: "FOOBAR"}raise"Server doesn't support our pretend SASL mechanism"inSecurityCapabilityError{command: "AUTHENTICATE" | "STARTTLS"}raiseSecureAuthUnsupportedErrorinSecurityCapabilityErrorraiseerrorincommand: "SELECT" | "EXAMINE",capability: "QRESYNC"error.run_alternate_commandsdo# a theoretical API for gracefully degradingendincapability: "X_PLEASE_WARN"logger.warn{"X_WARNING: error.warning"}incapability: "X_PLEASE_WARN_2"# let Net::IMAP handle warning via $stderr# just like client.enforce_capabilities = :warn:warnincapability: "BINARY"# let Net::IMAP raise the error# just like client.enforce_capabilities = truetrueincapability: "X_THIS_CLIENT_ALLOWS_IT"# ignore the missing capability# just like client.enforce_capabilities = falsefalseelse# use the default behavior for this version of Net::IMAP, i.e. warn now, raise later# just like client.enforce_capabilities = nilnilendend
The text was updated successfully, but these errors were encountered:
FWIW, I've already implemented much of this in my forked IMAP client. But I haven't implemented the (configurable) backward-compatible error handling yet. Capabilities handling is the next thing on my list to merge & implement, because it's needed for several of the other extensions.
The API for Net::IMAP#ignore_server_capabilities= in the description is just a proposal. Please let me know what you think. Hopefully I'll have code and proper documentation soon.
ENABLE
(included inIMAP4rev2
) #33LOGINDISABLED
capability: MUST not allowLOGIN
#32AUTHENTICATE
without matchingAUTH=#{mechanism}
capability #48STARTTLS
capability #134Using capabilities information
The client should track whenever it is knowingly violating capabilitied, either server reported or client enabled. At the very least, this should include checking capabilities before sending specific commands or command arguments.
Client-enabled capabilties
There will be no API to work around
client.enable(capability)
. Users who are determined to evade this limitation can figure out how cheat withclient.instance_variable_set(...)
.Server reported capabilities
The server capabilties cache will always be kept up-to-date when capabilities are checked. If the server hasn't sent its capabilities unsolicited, the client will request
capabilties
whenever capabilities are checked.If the capabilities check fails:
CapabilityError
will be raised without issuing any command to the server,CapabilityError
will be raised without issuing any command to the server,$stderr
but the command will still be sentIn some future version of
Net::IMAP
(perhaps the version released with ruby 3.2 or 3.3), the default for existing commands should change to match the behavior for new commands.Configuration
To opt-out of the new behavior or to opt-in to more strict behavior:
Net::IMAP#enforce_capabilities=
nil
-- Uses the current default behavior, which can change in future releases.true
-- Always raise an exception for any failed capabilities checks. Never knowingly sends unsupported commands or command arguments to the server.:warn
-- Prints a warning to$stderr
for non-security-related capabilities, regardless of the command or the currentNet::IMAP
default. Still raises for security-related capabilities checks.false
-- Restores old default behavior: client doesn't care about server capabilities. Still warns for security-related capabilities checks.def []: (CapabilityError, Net::IMAP) -> (nil | true | false | :warn)
, eg. aProc
. May change security-related capabilities handling.. The command, command args, required capabilities, etc will all be available on CapabilityError.Net::IMAP#initialize(*args, **kwargs, enforce_capabilities: cfg)
Net::IMAP.new(...).tap {|client| client.enforce_capabilities = cfg }
Net::IMAP#cmdname(..., enforce_capabilities: cfg)
#cmdname
represents any command which might check server capability.#starttls
,#authenticate
,#login
.opting out of security errors
enforce_capabilities: false
will still raise a warning for security related violations. These warnings can only be disabled with a proc.Allow fine-grained configuration with a Proc
The arguments will be a
CapabilityError
exception (which can be raised) and theNet::IMAP
client object (in case the proc is shared between multiple clients).CapabilityError
should have at least one sub-class,SecurityCapabilityError
, to representLOGINDISABLED
,AUTH=
,STARTTLS
capabilities, etc.CapabilityError
and its subclasses should allow pattern matching via#deconstruct
and/or#deconstruct_keys
This could be used to:
net-imap
yetThe text was updated successfully, but these errors were encountered: