Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2678
  • Last Modified:

Canon iR5055 can't email scanned PDF's outside our local domain

We scan lots of documents in as PDF files on our iR5055.  Emailing these scans within our domain works fine, but sending to outside addresses doesn't.  Using Exchange 2003.  When sending to a Road Runner account, I see the outbound mail sitting in Exchange's Road Runner send que until it times out.  Road Runner never accepts the email.  When sending to an AOL account, the emai goes through, but the PDF is corrupted.  

With so much recent malware and spyware being sent via PDF's, it makes sense that the ISP's are being very careful.  What is it about the iR created PDF's that is causing the problems with these outside ISP's?
0
pwashburn
Asked:
pwashburn
  • 10
  • 5
  • 3
1 Solution
 
rindiCommented:
Possibly the sent documents don't have a subject. Most mail servers will not accept mails that don't have a subject. Also they often check if the from address is an existing address and mail domain or not. So if that is missing they'll also reject such mails.
0
 
pwashburnAuthor Commented:
They do have a subject in them.  The From address is a made up name; ie,  CanonScanner@MyDomain.com, so that could be a problem.  Mail delivery for real users in our domain (ie. they have a full Exchange mailbox) gets delivered fine.  So I know the domain validation process is okay.  Didn't realize that there was some address validation going on as part of the SMTP Port 25 relaying process.  So, if I create a user in our domain named CanonScanner and create an Exchange mailbox for the user, that should cure the problem?  
0
 
rindiCommented:
I don't know, just try it.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
pwashburnAuthor Commented:
Will try this afternoon....
0
 
pwashburnAuthor Commented:
Tried changing the Sent From: address the scanner uses to a legitimate user on our domain.  Same problem.
1.  Goes through fine to someone on our domain
2.  Road Runner refuses it (but does take other attachments sent in other emails, including PDF's.)
3.  AOL accepts it, but it is a corrupted file (AOL says "Insufficent data for an image")

If I forward the email delivered to an internal email address sucessfully on to AOL, the image comes through fine.  Road Runner accepts and displays the email forwarded this way as well.

Could there be an issue with the communications protocols that the Canon scanner is using to communicate with the outside world?  When Exchange accepts the message for our local domain users all is well, but when it relays it on to Road Runner or AOL something is missing or not correct in the way it sends it's email through Exchange?

Is there logging on Exchange that I could look at to see why Road Runner has refused the connection with the email in it and why it's sitting in the Exchange que for a retry?
0
 
rindiCommented:
I don't know. I think you'll have to use the "Request Attention" button to attract more experts.
0
 
wyliecoyoteukCommented:
Is there a size limit on either email server?
Also, make sure that the copier is not set to divide and send email larger than a certain size, as that seldom works for PDFs.
Try sending it as a .Tif, see if that works.
0
 
pwashburnAuthor Commented:
The test PDF is only about 50K, so it shouldn't be a problem.  Remember seeing a divide option in the copier and it was off.  10Mb limits on both copier and Exchange.  I'll try the TIF option on Monday.  Thanks
0
 
wyliecoyoteukCommented:
Could also be compression settings with PDFs, I have had that cause issues in the past.
0
 
pwashburnAuthor Commented:
Been a little tied up the last couple of days, so I haven't had the chance to try the emailing the scans as a TIF attachment to see if that works.  That would give me clues where to go next.

0
 
pwashburnAuthor Commented:
Okay.  Scanned a document in as a TIF and tried emailing it with the same results.  So, I don't think it's a copier issue, but rather an SMTP Relay issue.  Looking at the headers of the email when I receive in our local domain Exchange email, here's what I see:

Microsoft Mail Internet Headers Version 2.0
thread-index: ActK3QBJ4XQ7d2PERzmrJ+RvnguuAg==
Content-Type: image/tiff;
      name="0757_001.tif"
Received: from [192.168.10.113] ([192.168.10.113]) by MyDomain.com with Microsoft SMTPSVC(5.0.2195.7381); Thu, 2 Sep 2010 16:25:36 -0400
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Content-Disposition: attachment;
      filename="0757_001.tif"
From: <canon@MyDomain.com>

The copier sends the email to our Exchange server through SMTP.  I've setup our Exchange server to allow Relaying from the copiers IP address (192.168.10.113).  So Exchange merrily sends it on it's way.  Or at least tries.  The message sits in Exchange's Ques until they time out.

My guess is that the ISP as part of their Spam Filtering are trying to do a Reverse DNS lookup on the 'received from' IP address of the email, which is 192.168.10.113, which of course isn't going to be resolved as it's a private IP address.

So, is there a way I can tell Exchange to change the 'Received From' address to from the Canon's private IP address to the public IP address of our Exchange server?   Then the ISP's can do the reverse lookup and suceed as our Exchange server has all the DNS records it needs.
0
 
wyliecoyoteukCommented:
Might be worth setting the copier up with a valid domain hostname. private IP address ranges (as hostnames) would be blocked by default.
0
 
pwashburnAuthor Commented:
So I would create something in Active Directory to make the copier a valid part of our domain?  In the copier itself, all I can do is specify the SMTP parameters. I've obviously added computers to the domain, but not a non computer item.
0
 
wyliecoyoteukCommented:
The copier is just another computer.
I would suggest giving it a hostname in the web interface, (it may already have one) and adding a DNS record for it in your DNS server, so that it appears as <hostname.domainname> instead of an IP address.
0
 
pwashburnAuthor Commented:
I have created DNS records in both the Forward and Reverse lookup zones  on our Win domain DNS server.  Still doesn't show the name, comes through as the IP address.

I've setup within Exchange 2003 an email account for the scanner.  I can send SMTP email out through Exchange as that account and it goes out to the external domains with an attached PDF fine.  So I think that account is valid and setup.

Comparing the headers in the message between 'sending' a PDF and 'scanning' a PDF I see there are a few differences in the headers:

Content-Transfer-Encoding:
Canon scan
0
 
pwashburnAuthor Commented:
continued from last post....

Content-Transfer-Encoding:
Canon scan = 7bit
Emailed PDF = 8bit

Content-Type:
Canon scan = application/pdf
Emailed PDF = multipart/mixed

Message ID:
Canon scan = ends with canontxno.0958@[192.168.10.113]
Emailed PDF = ends with @org     (we're a .org organization)

Could this Message ID be what's tripping us up where it shows the private IP?

The application/PDF is a standard MIME type, so I don't think that is the problem.

I've got the same SMTP settings on the Canon as when I send from Outlook.
Server requires authetication.     Password
No encryption (SSL)
The only difference is that I define the SMTP server in the Canon by it's internal IP address rather than it's FQN.

Anyone have any other thoughts?   This just shouldn't be that hard!!!
0
 
wyliecoyoteukCommented:
I am pretty sure that the internal IP address in the from header is what's causing the problem.
somewhere in the canon configuration, you should be able to edit the host name.
Sorry, can't help much more, as this is obviously a canon specific issue, and I do not work on those machines.
0
 
pwashburnAuthor Commented:
No solutions have worked.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 10
  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now