Defanging URLs in incoming e-mails?

Hi all,

I’m setting up RT to handle incoming e-mails which may contain URLs
linking to malicious sites. We want to display incoming URLs so that our
users can’t accidentally click on them and visit the malicious site. We
also want to defang the URLs in the e-mails we send out so that our
users’ mail clients don’t cleverly linkfy them and make it easy for our
users to accidentally click on them.

It looks like the first goal, and only the first goal, is easily achieved
via extending MakeClicky. Accomplishing the second goal might achieve the
first goal as well, however.

It looks like RT’s MailPlugins are only for go/no-go filtering and
authentication, and aren’t intended to be used to modify the body of the
message before it is made into a transaction. (Or will changes to the
MIME::Entity be honored?)

It looks like Scrips are processed too late. I could of course modify
their templates to defang the URLs before sending, which together with
MakeClicky would solve the problem, but I’d prefer not to store the
offending URLs undefanged in the database at all.

Is there a better way to do this that I’m missing?

  • Kevin

It looks like Scrips are processed too late. I could of course modify
their templates to defang the URLs before sending, which together with
MakeClicky would solve the problem, but I’d prefer not to store the
offending URLs undefanged in the database at all.

Is there a better way to do this that I’m missing?

Something like MIMEDefang in the MTA might be one way to go.

It looks like RT’s MailPlugins are only for go/no-go filtering and
authentication, and aren’t intended to be used to modify the body of the
message before it is made into a transaction. (Or will changes to the
MIME::Entity be honored?)

MailPlugins which are “ApplyBeforeDecode” can completely alter the
MIME::Entity, I believe. Start reading the code in
RT::Interface::email::Gateway().

It looks like RT’s MailPlugins are only for go/no-go filtering and
authentication, and aren’t intended to be used to modify the body of the
message before it is made into a transaction. (Or will changes to the
MIME::Entity be honored?)

MailPlugins which are “ApplyBeforeDecode” can completely alter the
MIME::Entity, I believe. Start reading the code in
RT::Interface::email::Gateway().

Either step can adjust MIME::Entity and actually ApplyBeforeDecode is not
the right place. This stage is for plugins that want access to mail as it
was including content transfer encoding.

What kind of defanging do you want to achieve?

Best regards, Ruslan.

It looks like RT’s MailPlugins are only for go/no-go filtering and
authentication, and aren’t intended to be used to modify the body of the
message before it is made into a transaction. (Or will changes to the
MIME::Entity be honored?)

MailPlugins which are “ApplyBeforeDecode” can completely alter the
MIME::Entity, I believe. Start reading the code in
RT::Interface::email::Gateway().

Either step can adjust MIME::Entity and actually ApplyBeforeDecode is not
the right place. This stage is for plugins that want access to mail as it
was including content transfer encoding.

What kind of defanging do you want to achieve?

Approximately s#http://malicious.example.com/foo/bar#hXXp :// malicious
[.] example [.] com / foo / bar#, over the entire message. (I’ll actually
build it with Regexp::Common::URI, of course.)

  • Kevin