I don't think there's a set standard. Some CASE tools may be picky, but the majority of software engineers use UML to design, not to generate code, in which case the goal is to increase communication effectiveness.
I've found that the presence of data-carrying objects, especially if they are only used in method arguments and return values, tends to obscure the important interactions.
Here is what I would do:
If you use these classes in multiple locations, it is often ok to pick a separate area of the diagram as a "legend", and organize these classes in alphabetic order. There is no need to clutter the diagram with these or with extra arrows - the repeated in the signatures is sufficient. Make it easy for someone to find these. A separate legend sheet (if using posterboards) is particularly good.
If the class is only used in the communication between a very small set of classes, then it might make more sense to place it somewhere on the lines of interaction between them.
Finally, if your data objects are used to communicate between tiers (e.g., serialized data between client and server), you might want to draw each tier on a separate side and line these up in the middle.
Oh, and if the data relations inside the data carrying objects are complex, don't hesitate to use ERDs or your favourite database related notation in the class diagram. The goal is to design, not to focus on formalism.