Invalid FROM/SENDER addresses?

Unanswered Question
Nov 10th, 2009

What is everyone's thoughts/expierence with trying to enforce valid FROM e-mail addresses? I work for an organization of 16,000 users and currently any IT person can write a script to send e-mail FROM any address even an invalid one. The problem that I'm seeing is now this e-mail has no valid place to bounce back to if it fails to deliver for whatever reason. This has caused everything from thousands of e-mails queued up on our appliances that have no place to deliver to, to the IT person not being able to track down a simple delivery failure because it couldn't come back to their mailbox. The big concern that I have is when e-mail leaves our environment with an invalid FROM address, I'm guessing this can't be good for our sender reputation. Any thoughts? Do I try to enforce valid FROM/Sender e-mail addresses?

Thanks and LONG LIVE THE NATION!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
shannon.hagan Thu, 11/12/2009 - 19:39

If you do you may find a lot of automated applications aren't using valid from fields.

jason.meyer@neb... Thu, 11/12/2009 - 19:54

I've all ready found them and yeah, it's ugly. I'm just wondering if I clean it up or look the other way. I want to clean it up and have a good oppurtunity to do so but just wondering what everyone else's thoughts/expierience is. I'm concerned that at somepoint we will get blacklisted becasue some automated program sent a million e-mails to the wrong external domain and all eyes fall upon me and they say why did the IronPort appliances allow this???

mychrislo_ironport Fri, 11/13/2009 - 03:27

In a way, your first target is to, at least, enforce outgoing (relay) mails are originating from your own domains. right?

So at least they dont bounce back to domains you do not own.

So you can try header-dictionary-match on mail-from and do something (drop/modify/archive?)

If you cannot drop them, I'd also setup a lame mta to process them by alt-mailhost these "less-legitimate" messages i.e. let the lame mta has all the bad reputation.

Eisenhafen Fri, 11/13/2009 - 08:12

In a way, your first target is to, at least, enforce outgoing (relay) mails are originating from your own domains. right? 

To do exactly this I'm considdering to use a messagefilter, it could just use my RAT or SMTP Routes, so I wouldn''t have to change the filter everytime we add or delete a domain.

Any idea?
mychrislo_ironport Fri, 11/13/2009 - 10:10

In a way, your first target is to, at least, enforce outgoing (relay) mails are originating from your own domains. right? 

To do exactly this I'm considdering to use a messagefilter, it could just use my RAT or SMTP Routes, so I wouldn''t have to change the filter everytime we add or delete a domain.

Any idea?


Most people already have LDAP, you can simply use group query for valid domain lookup.

e.g.

Edit Outgoing Mail Policy -> LDAP Group query (you need to create that query first in LDAP submenu). Select the query.

Problem with this method is that. Once a mail policy is hit, it will not process the rest of the policies. i.e. in my case, I have many policies serving different purposes. Then one policy is not sufficient.
Eisenhafen Fri, 11/13/2009 - 10:13

yes, that would be nice, unfortunately not all domains in our case have LDAP.

jason.meyer@neb... Mon, 11/29/2010 - 13:19

Just checking to see if there has been any further developments on this topic from CISCO/IronPort.

I took over an installation that had 200+ domains that we hosted and I'm narrowing that down to one.  Due to the number of e-mail domains we had the IronPort appliances were basically originally configured to allow anything from our internal network to be delivered.  Now that we have consolidated down to only a handful of e-mail domains I am starting to clean this up. 

Currently I am just using mail polices that does a LDAP lookup on the sender address and then in a policy following that I use a content filter on the Sender header.  Any sent e-mail that misses the LDAP lookup is invalid and then I have a content filter on the following policy looking for that same domain.  If the content filter has any hits the sender must not have been in the LDAP and thus invalid.

I also have some e-mail domains that are sending e-mail via my appliances that I don't have access to LDAP for and I guess I could use the Envelope Sender matches dictionary content method.

The challenge that I'm starting to find though is if someone has 'forwarding' turned on an account.  Still working to find a way to resolve that.

Anyway, wanted to send the discussion to the top and see if anyone else out there was fighting the good fight. 

Long live the Nation!

Jason

andmuell Wed, 12/01/2010 - 05:01

Hello Jason,

another possibility of using LDAP for sender verification is described in this knowledge base article, where a public listener is modified to relay outbound messages.

http://tinyurl.com/cutsb8

(if anybody cannot access it please let me know, and I'll post the solution here). The advantage of this is that messages with invalid senders get bounced right away before they enter the workqueue, so no filter needed. Drawback is that it needs to be implemented carefully, otherwise, with a RAT set to "Allow" on anything, a wrong LDAP query could make that appliance to be an open relay.

Hope that helps,

Andreas

mychrislo Fri, 01/14/2011 - 21:11

Long Live the Nation!

I am wondering if you drop those "invalid" from mails after you do ldaplookup and content filter check.

Any complaints?

As you already go this far already. And in your environment, seems you can do

if all check fails

- you can drop it

OR

- you can actually rewrite the return address into one of your dedicated domain (say. blackhole@bounce.yourdomain.com)

- (may need resent-from or x-original-mailfrom header)

- let these go outbound

- inbound , drop anything to (blackhole@bounce.yourdomain.com)

endif

Chris Lo

Actions

Login or Register to take actions

This Discussion

Posted November 10, 2009 at 8:32 PM
Stats:
Replies:9 Avg. Rating:
Views:442 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard