Comment On Simplifying Email With Web Services

No "First Post" posts for you today.

I should note that this is actually from code that I've personally come across. It is part of that company's new "SOA Vision" and is the recommended way of sending emails. This is the only publically avaiable method in the three-assembly solution contained within ...

The problem with XML and web services is that people love passing XML into web services. God I hate that. That's why methods have parameters / arguments.

This is so stupid.

I wonder what the guys who invented SMTP think about this....

 

Let me get this right, you have to create the xml string somewhere else and send it to this function which will then split it up or doing something with this string. Come on, new ways using new tech are not always the best!!!! They were probably like "Look Guys/Gals I used XML!!!!"

Bus Raker:

I wonder what the guys who invented SMTP think about this....

 

 

They probably thought about it then said what the heck lets do it better!

Alex Papadimoulis:

No "First Post" posts for you today.

I should note that this is actually from code that I've personally come across. It is part of that company's new "SOA Vision" and is the recommended way of sending emails. This is the only publically avaiable method in the three-assembly solution contained within ...

 

Did they want to limit which mahines could send email?  By forcing all the other apps to send their email through this one app they could channel the email generation and force all email to come from one enterprise server instead of many scattered around the enterprise.  This would allow them to leave the SMTP server stump removed for all servers except the one that hosted the webservice and then could configure their mail servers to only relay for that one address. 

I'm not justifying this but I could see this design coming out of some "lockdown" requirement.

 

Anonymous:

The problem with XML and web services is that people love passing XML into web services. God I hate that. That's why methods have parameters / arguments.

This is so stupid.

Or, in other words, there's nothing wrong with XML and web services you couldn't fix by removing the XML and web services parts.

This proves it:  object-oriented programming sucks!  Look how hard that is!



More seriously, I've seen projects where every last data type and
method of the system is defined in XML.  No wonder people hate
it.  Where does the notion that such things are a good idea even
get its start?



I mean, some WTFs are easily attributed to premature optimization, or
an obvious lack of knowledge of a language's capabilities.  But
what drives the hideous mis-application of XML?

The WTF isn't centralizing this feature in a web service, it's passing an XML string to a web service.

VGR:

This proves it:  object-oriented programming sucks!  Look how hard that is!



More seriously, I've seen projects where every last data type and
method of the system is defined in XML.  No wonder people hate
it.  Where does the notion that such things are a good idea even
get its start?



I mean, some WTFs are easily attributed to premature optimization, or
an obvious lack of knowledge of a language's capabilities.  But
what drives the hideous mis-application of XML?

Not only is XML a syngergistic new technology which leverages the dynamism of text processing, but some people genuinely think that because all information encoded in XML uses the same document format, it makes any document written in XML interoperable with any application.

There was a fellow in Hell
Said "things are going too well"
I'll put a stop
to work in that shop
They'll worship their new XML

Nothing is wrong w/ web services.  You can use XML-RPC, SOAP, Rest.  The key is to use an abstraction layer that makes everything seem local.  I could imagine SmtpMail.Send(email); being backed by something from the above.

The true WTF in this is taking multiple parameters AS XML and parsing it. A good SOAP, XML-RPC library would let your function exist w/ regular, every day, normal parameter passing, and abstract the XML stuff away from it.

e.thermal:

Did they want to limit which mahines could send email?  By forcing all the other apps to send their email through this one app they could channel the email generation and force all email to come from one enterprise server instead of many scattered around the enterprise.  This would allow them to leave the SMTP server stump removed for all servers except the one that hosted the webservice and then could configure their mail servers to only relay for that one address. 

This was not a reason AFAIK; simply a result of the SOA vision.

I should note that the "lockdown" scenario did already exist due to blocking of outbound port 25. The "old" way of sending email simply involved creating an application setting which could point the application to the SMTP server, which was allowed to go outside on port 25.

The "new" way of sending email dictates that an application setting is created to configure the URL of the Email webservice which, in turn, has an application setting to configure the address of the SMTP server.

The irony here (for those of you unused to .NET and/or Web Services) is that a "WebMethod" is called by creating an XML packet on the client, requesting the service and passing along the data in the signature in the packet.

Meaning this XML encoded String will be XML encoded, sent on the pipe, then XML decoded back to an XML String.

I will admit to -- once -- doing something similar, to leverage the power of databound XML datasets while improving throughput.  I zipped up the XML and sent the Base64 of THAT over XML.  Microsoft had a solution for piping a compression routine, but that zipped the contents of the dataset but not the tags themselves, leaving the greatest amount of redundancy STILL IN the datastream.  But I had planned all along to redo this if it became necessary to change the XML, which it didn't (before I left anyway).

Alex Papadimoulis:

... and for the Office Space (the movie) deprived, company name changed to protect the architects.

Why do you want to protect the architects?  Are you running short on submissions?

Sincerely,

Gene Wirchenko

Bus Raker:

I wonder what the guys who invented SMTP think about this....

 

Actually, XML *would* be a decent way to send emails. I mean, emails are just text anyway, right? I can see it now... XMTP, the eXtensible Mail Transfer Protocol!!!  :ducks:

Anonymous:

Actually, XML *would* be a decent way to send emails. I mean, emails are just text anyway, right? I can see it now... XMTP, the eXtensible Mail Transfer Protocol!!!  :ducks:

Weeehell, whadayaknow, it's been done:

http://xml.coverpages.org/xmtp.html

Alex Papadimoulis:

No "First Post" posts for you today.

I should note that this is actually from code that I've personally come across. It is part of that company's new "SOA Vision" and is the recommended way of sending emails. This is the only publically avaiable method in the three-assembly solution contained within ...

Im f1rst!!! 

Oh wait.  Never mind.

Not only is XML a syngergistic new technology which leverages the dynamism of text processing, . . .

It's lines like this that help keep the Emporer's new clothing shop a going concern. . .

Gene Wirchenko:

Why do you want to protect the architects?  Are you running short on submissions?

A professional courtesy I suppose -- and plenty of submissions in the pipeline. But it was high time I got one of mine in.

Anonymous:

Anonymous:

Actually, XML *would* be a decent way to send emails. I mean, emails are just text anyway, right? I can see it now... XMTP, the eXtensible Mail Transfer Protocol!!!  :ducks:

Weeehell, whadayaknow, it's been done:

http://xml.coverpages.org/xmtp.html

I challenge some one to make a joke about integrating XML with some existing technology that someone hasn't already (or, is in the process of) actually implementing.

The best I came up with was defining an image format (like JPEG, GIF, etc) in XML. And then some one pointed me to SVG. Hoo boy.

Owned! lol

e.thermal:

Did they want to limit which mahines could send email?  By forcing all the other apps to send their email through this one app they could channel the email generation and force all email to come from one enterprise server instead of many scattered around the enterprise.

This kind of defeatsthe point of SMTP and the Internet, which is that any machine can send a message to any other machine by using the right address.   If we're centralizing everything, then those addresses above might as well be  "mynode!mygateway!initech-global-gateway!initech-mail-server!jdoe" :)

And we might as well just be dialing up the central server over phone lines too...

Alex Papadimoulis:

No "First Post" posts for you today.

damn you Papadimoulis.  I will have my revenge!

-ds

Alex Papadimoulis:

The best I came up with was defining an image format (like JPEG, GIF, etc) in XML. And then some one pointed me to SVG. Hoo boy.

How about an XML file that includes bitmap data? That would be a real WTF.

<image>
 <row>
   <pixel r="255" g="0" b="128" />
   <pixel ...
   ...

reed:

This kind of defeats the point of SMTP and the Internet, which is that any machine can send a message to any other machine by using the right address.

They already did away with that. It's called "SPF" aka "Sender Policy Framework" aka "Sender Permitted From". Lots of domains implement it now, as it's just an extra entry into their DNS records. Basically prevents you from sending email from a domain name if the domain name doesn't have you allowed as one of the permitted senders of that domains email. The receiver is required to check, of course, but it basically stops email spoofing, if implemented correctly all around.

Alex Papadimoulis:

I challenge some one to make a joke about integrating XML with some existing technology that someone hasn't already (or, is in the process of) actually implementing.

The best I came up with was defining an image format (like JPEG, GIF, etc) in XML. And then some one pointed me to SVG. Hoo boy.

I started to create a LISP-like language using XML as the input format (since an XML DOM tree and a LISP-list are very, very similar) as a joke once. You'd get syntax like:


<plus><number value="1"/><number value="2"/></plus>

<if><greater-than><variable name="a"/><variable name="2"/></greater-than><number value="1"/><number value="2"/></if>


It was great... Unfortunately I've since lost the source code.


(And, no, it was not supposed to be useful for anything. Just extremely ugly and extremely verbose.)


(And for what it's worth, SVG is quite a bit different from JPEG in GIF - SVG uses vectors (like Flash), JPEG and GIF are raster-based. Although you can actually embed JPEG and GIF images into SVG using BASE64 encoding...)

Depend on the situation, it's not entirely WTF.

We have a system that parse EDI (Text-formated data - headaches - before XML days) to XML to be import to the database or send to other vendors.  The xml can go through a series of transformation which can create xml email files with similar format as above.  (Body tag is of course of type CDATA.)

Then there are other things like:

1.  Send email should be simple as calling a method.

2.  Microsoft System.Web.Mail.SmtpMail in .NET 1.1 is actually a wrapper around COM stuff, which is going to be changed in 2.0.  This support criteria 1 because all we need to do is replace one method instead of code everywhere.

3.  We are a small company, running our own exchange server which often crashes.  We don't want email failsure to interrupt the application (especially our automated EDI applications).  The email service should store these email and automatically retry sending to the smtp/exchange server on failure.  It will be a simple persist since the email message is in XML.

Also remember you can define an object XML serializable, which serialize as an xml file that you can simply deserialize it back into an object.

Of course, we didn't stop with just one method.  We added/overloaded a couple more methods to make it simple to use, which is probably what the code above need.  Example: .Send(from, to, message, isHtml), .Send(from, to, bcc, message, isHhtml), etc...

All our application can now take advantage of the webservice without having to worry about those other things.

I did that once too, actually. And I made an XSLT stylesheet that displayed it as an HTML table. Unfortunately, it was too horrifying to be funny.

Salta Mada:

I did that once too, actually. And I made an XSLT stylesheet that displayed it as an HTML table. Unfortunately, it was too horrifying to be funny.

That was intended as a reply to Reed's message above, by the way.

... if it does not work, use more!

Anonymous:

Nothing is wrong w/ web services.  You can use XML-RPC, SOAP, Rest.  The key is to use an abstraction layer that makes everything seem local.  I could imagine SmtpMail.Send(email); being backed by something from the above.

Actually, XML-RPC and SOAP are WTFs.

Well, this isn't that bad of a WTF.

I've seen this before in COM projects from 2000-2005 (big COM objects written with single methods that only accept a string param... inside was a shitload of XML unwinding).  Now we've just reinvented that same old paradigm on a newer platform.

If the developer/misarchitect ever forces symmetrical encryption so the plaintext SOAP has an encrupted message, then coding it this way makes it a piece of cake.

However, if you wanted to encrypt your SOAP you could just slap on SSL.  Any *DECENT* HTTP getter has an HTTPS implementation as well.

Anonymous:

Depend on the situation, it's not entirely WTF.

3.  We are a small company, running our own exchange server which often crashes.  We don't want email failsure to interrupt the application (especially our automated EDI applications).  The email service should store these email and automatically retry sending to the smtp/exchange server on failure.  It will be a simple persist since the email message is in XML.

Many SMTP servers support this feature of queue'ing undeliverable email and retrying over a period of time.  What you normally do is create an outgoing SMTP server, w/ some plasuable retry times.  No incoming smtp from "the world".  Anytime you need to send out email to the world, have your app servers pipe all requests through it.

A lot easier than creating a new service that does the same thing as an MTA would do anyway.

I gotta admit, I'm not really seeing the WTF here. There are circumstances where this could be useful, like if everything but port 80 was blocked, etc. Stupid security policies are responsible for lots of this sort of thing.

After running that through an XML DOM parser, you'd have stuff like:
EmailMessage.From.Address.Name = "John Doe"
EmailMessage.From.Address.Email = "jdoe@initech..."
EmailMessage.Subject = "Test Email..."
EmailMessage.Body = "This contains..."

...and so forth. Yeah, so it's making the communication between the client and server ridiculously long, but other than that it's not particularly bad. On-the-fly gzip compression makes the communication ridiculously small as there's a lot of redundancy in text, so BFD.

Most likely the reasons for this code is simple:
1. Initech had to implement a means for clients to send email but they had to go through a normal server in order to do it.
2. A webservice may have been specified in the requirements, or it may have been part of a series of webservices for various purposes, in which case it's easier to reuse existing code.
3. Opening port 25 to the clients was not possible due to f---ed up security restrictions (this has been the case for ages in lots of companies, to slow/stop the spread of email worms), and thus using straight SMTP was not an option.
... and so on. Lots of possible reasons for implementing this, and it's a fairly simple implementation anyway (no support for attachments for example).

Contrary to Alex's opinion, use of XML is not a WTF all by itself. SVG is a quite handy format, for example. A bit wordy, but still incredibly useful as it's an actual *standard* for vector graphics formats, something that never really existed before and a great boon to those people who have to work with vector graphics on a regular basis.

How about an XML file that includes bitmap data? That would be a real WTF.

You are kidding, right? It is totally wrong, you would have to do something like:



<image>

  <row>

    <pixel>

      <red>255</red>

      <green>0</green>

      <blue>128</blue>

    </pixel>

  </row>

</image>



Or even:



(...)

<pixel layout="rgb">

    <component name="red">255</component>

    <component name="green">0</component>

    <component name="blue">128</component>

</pixel>



Back to the subject of implementing an already existent technology to
XML, I would suggest the Windows Message Model. That would be perfect,
no more LPARAMs and WPARAMs. Man, that would be really awesome :D





(no need to say "sarcasm", uh?)

e.thermal:

Did they want to limit which mahines could send email?  By forcing all the other apps to send their email through this one app they could channel the email generation and force all email to come from one enterprise server instead of many scattered around the enterprise.  This would allow them to leave the SMTP server stump removed for all servers except the one that hosted the webservice and then could configure their mail servers to only relay for that one address.

See my comment below about outgoing SMTP servers that queue.

Alex Papadimoulis:

I challenge some one to make a joke about integrating XML with some existing technology that someone hasn't already (or, is in the process of) actually implementing.

The best I came up with was defining an image format (like JPEG, GIF, etc) in XML. And then some one pointed me to SVG. Hoo boy.

Ooooh... that's asking for a world of hurt.  How about "Secure Shell through XML?" or perhaps ANSI or RIP Graphics using an XML transport layer.

Perhaps even the XML Human Genome project?  (On a side note, since we already have it decoded, who's going to write the emulator?)

Anonymous:

The irony here (for those of you unused to .NET and/or Web Services) is that a "WebMethod" is called by creating an XML packet on the client, requesting the service and passing along the data in the signature in the packet.

Meaning this XML encoded String will be XML encoded, sent on the pipe, then XML decoded back to an XML String.

I will admit to -- once -- doing something similar, to leverage the power of databound XML datasets while improving throughput.  I zipped up the XML and sent the Base64 of THAT over XML.  Microsoft had a solution for piping a compression routine, but that zipped the contents of the dataset but not the tags themselves, leaving the greatest amount of redundancy STILL IN the datastream.  But I had planned all along to redo this if it became necessary to change the XML, which it didn't (before I left anyway).

 

Ahh but you are missing the true "genius" (yeah right) of this.  They probably did it this way instead of defining parameters on the method so that later in life when the method changes or gets upgraded the outward facing interface does not change.  Say they defined their parameters properly methoname(param1, param2, param3) then needed a forth parameter they would have to upgrade the interface and risk breaking older apps, with this "solution" they never break compatibility.   

I see this a lot actually, but instead of XML I see it with tab or bar delimited strings.  It's all poo

VGR:

This proves it:  object-oriented programming sucks!  Look how hard that is!



More seriously, I've seen projects where every last data type and
method of the system is defined in XML.  No wonder people hate
it.  Where does the notion that such things are a good idea even
get its start?



I mean, some WTFs are easily attributed to premature optimization, or
an obvious lack of knowledge of a language's capabilities.  But
what drives the hideous mis-application of XML?

Object orientation is not what sucks here. What sucks is their web service's interface requiring an XML string as a parameter. That's more than stupid.

Anonymous:

Anonymous:

Depend on the situation, it's not entirely WTF.

3.  We are a small company, running our own exchange server which often crashes.  We don't want email failsure to interrupt the application (especially our automated EDI applications).  The email service should store these email and automatically retry sending to the smtp/exchange server on failure.  It will be a simple persist since the email message is in XML.

Many SMTP servers support this feature of queue'ing undeliverable email and retrying over a period of time.  What you normally do is create an outgoing SMTP server, w/ some plasuable retry times.  No incoming smtp from "the world".  Anytime you need to send out email to the world, have your app servers pipe all requests through it.

A lot easier than creating a new service that does the same thing as an MTA would do anyway.

I don't think it can queue when it crashed! - Sarcasm

Administrator sometime restrict send/relay email through the smtp server by IP Address to prevent spammer or some other security reasons.  All you need is to set the permission for the webservice machine(s).

 

Alex Papadimoulis:

e.thermal:

Did they want to limit which mahines could send email?  By forcing all the other apps to send their email through this one app they could channel the email generation and force all email to come from one enterprise server instead of many scattered around the enterprise.  This would allow them to leave the SMTP server stump removed for all servers except the one that hosted the webservice and then could configure their mail servers to only relay for that one address. 

This was not a reason AFAIK; simply a result of the SOA vision.

I should note that the "lockdown" scenario did already exist due to blocking of outbound port 25. The "old" way of sending email simply involved creating an application setting which could point the application to the SMTP server, which was allowed to go outside on port 25.

The "new" way of sending email dictates that an application setting is created to configure the URL of the Email webservice which, in turn, has an application setting to configure the address of the SMTP server.

Does the " SmtpMail.Send(email)  " function require an smtp service to be running on the server hosting the code ?  If so, I could see  where using the webservice is a potential security boost because it  removes  the need for SMTP to be running ...

Anonymous:

e.thermal:

Did they want to limit which mahines could send email?  By forcing all the other apps to send their email through this one app they could channel the email generation and force all email to come from one enterprise server instead of many scattered around the enterprise.  This would allow them to leave the SMTP server stump removed for all servers except the one that hosted the webservice and then could configure their mail servers to only relay for that one address.

See my comment below about outgoing SMTP servers that queue.

Having queues on SMTP servers still wouldn't deal with the problem that some network administrators impose in which only designated servers can run SMTP software, either send or receive on port 25.  Through port filtering and IP sec many machines I have seen are locked down corporately and cannot no matter what communicate on very many ports, outside of port 80.   So I have seen better although similar solutions to this to solve the problems that corporate IT groups impose.

Anonymous:

Alex Papadimoulis:

e.thermal:

Did they want to limit which mahines could send email?  By forcing all the other apps to send their email through this one app they could channel the email generation and force all email to come from one enterprise server instead of many scattered around the enterprise.  This would allow them to leave the SMTP server stump removed for all servers except the one that hosted the webservice and then could configure their mail servers to only relay for that one address. 

This was not a reason AFAIK; simply a result of the SOA vision.

I should note that the "lockdown" scenario did already exist due to blocking of outbound port 25. The "old" way of sending email simply involved creating an application setting which could point the application to the SMTP server, which was allowed to go outside on port 25.

The "new" way of sending email dictates that an application setting is created to configure the URL of the Email webservice which, in turn, has an application setting to configure the address of the SMTP server.

Does the " SmtpMail.Send(email)  " function require an smtp service to be running on the server hosting the code ?  If so, I could see  where using the webservice is a potential security boost because it  removes  the need for SMTP to be running ...

 

Not necessarily but it does require tcp/ip communication to an smtp relay at the very least which is restricted in some enterprises.

 

 

Anonymous:

Alex Papadimoulis:

I challenge some one to make a joke about integrating XML with some
existing technology that someone hasn't already (or, is in the process
of) actually implementing.

The best I came up with was defining an image format (like JPEG, GIF, etc) in XML. And then some one pointed me to SVG. Hoo boy.

Ooooh... that's asking for a world of hurt.  How about "Secure
Shell through XML?" or perhaps ANSI or RIP Graphics using an XML
transport layer.

Perhaps even the XML Human Genome project?  (On a side note,
since we already have it decoded, who's going to write the emulator?)

Everytime some adds XML to a project for no reason, God kills a puppy.

e.thermal:

Having queues on SMTP servers still wouldn't deal with the problem that some network administrators impose in which only designated servers can run SMTP software, either send or receive on port 25.  Through port filtering and IP sec many machines I have seen are locked down corporately and cannot no matter what communicate on very many ports, outside of port 80.   So I have seen better although similar solutions to this to solve the problems that corporate IT groups impose.

That sounds like some backwards-ass team work.  You do realize that what you've written IS an MTA. 

That's when you explain to your manager that you could write the software yourself, which would cost your wages to write and QA's wages to test.  Or have your sysadmin and netadmin work together to create 1 single outgoing SMTP server that does this for you MUCH much cheaper.

Alex Papadimoulis:

I challenge some one to make a joke about integrating XML with some existing technology that someone hasn't already (or, is in the process of) actually implementing.

It won't take long before someone will come up with this:
XXML - eXtensible XML. It will look like this:

<Tag>
    <Attribute name="Tag"/>
    <Value>
        ...
    <Value>
</Tag>

Ha!

Anonymous:

Alex Papadimoulis:

I challenge some one to make a joke about integrating XML with some existing technology that someone hasn't already (or, is in the process of) actually implementing.

It won't take long before someone will come up with this:
XXML - eXtensible XML. It will look like this:


   
   
        ...
   


Ha!

Brillant!

Anonymous:

The problem with XML and web services is that people love passing XML into web services. God I hate that. That's why methods have parameters / arguments.

This is so stupid.

I know, the whole point of the web services features in .NET is so you don't have to fuck with XML!!! Just accept some plain old parameters so the IDE/Framework can create the XML for you dipshit! 

Besides that, I'm beginning to notice a trend:

SOA = Hammer;
EveryThingElse = Nail;

while (true)
   Hammer.Pound();

 

 

M5, 760K, HANGIN WIFF D-ROD AND THE HUSTLAS.

YOU CAN NOT AFFORD![:(]

Anonymous:

How about an XML file that includes bitmap data? That would be a real WTF.

You are kidding, right? It is totally wrong, you would have to do something like:



...

(no need to say "sarcasm", uh?)

(Quoted section trimmed because I'm too lazy to re-insert all the angle brackets that get eaten (yummy!).

I'm curious how MIME-types are handled in either mechanism, although both have an equal shot at the same solution.  (E.g. an XML tag for a file to embed would be equivalent to such a field in the param ... although multiple such email attachments might ultimately seem more natural in the XML structure)

Personally, this sort of WTF rarely rankles me: I'll just create a utility to convert from a convenient interface to whatever the system requires.  (Maybe I'll just find the one that converts whatever the system "requires" to what it actually uses, and reverse it.)  More work imposed by the system means more jobs for programmers, no?