Jump to content
Sign in to follow this  
kevdude70

Help debugging spamtrap Hits

Recommended Posts

Hi,

I work at Fermi National Accelerator Laboratory. One of our two email gateway machines has been blacklisted, apparently due to a spamtrap hit. As our two gateway machines relay email for our whole rather large campus network, any chance we can get some clues as to what actually hit the spamtraps?

the machine in question is:

mailgw2.fnal.gov 131.225.111.12

thanks,

-kevin

Share this post


Link to post
Share on other sites
the machine in question is:

mailgw2.fnal.gov 131.225.111.12

Only the Deputies can give you more specifics WRT spamtrap hits (and then only very carefully, due to security issues involving the secrecy of spamtraps), but I can show you what's currently visible in the reporting database regarding that IP:

Report History:

Submitted: Tuesday, August 29, 2006 4:38:38 AM -0700:

Undeliverable Mail

* 1897077711 ( 131.225.111.12 ) ( UUBE ) To: uube[at]devnull.spamcop.net

Submitted: Sunday, August 13, 2006 4:56:15 AM -0700:

Delivery Notification: Delivery has failed

* 1874901551 ( 131.225.111.12 ) ( UUBE ) To: uube[at]devnull.spamcop.net

Submitted: Sunday, August 13, 2006 4:48:54 AM -0700:

Delivery Notification: Delivery has failed

* 1874894897 ( 131.225.111.12 ) ( UUBE ) To: uube[at]devnull.spamcop.net

Submitted: Friday, August 11, 2006 10:35:39 PM -0700:

Delivery Notification: Delivery has been delayed

* 1873458310 ( 131.225.111.12 ) ( UUBE ) To: uube[at]devnull.spamcop.net

Submitted: Friday, August 11, 2006 5:13:18 AM -0700:

Delivery Notification: Delivery has failed

* 1872529922 ( 131.225.111.12 ) ( UUBE ) To: uube[at]devnull.spamcop.net

Submitted: Monday, July 31, 2006 10:42:09 PM -0700:

Delivery Notification: Delivery has timed out and failed

* 1859509758 ( 131.225.111.12 ) ( UUBE ) To: uube[at]devnull.spamcop.net

Submitted: Friday, July 28, 2006 10:37:09 PM -0700:

Delivery Notification: Delivery has been delayed

* 1856061545 ( 131.225.111.12 ) ( UUBE ) To: uube[at]devnull.spamcop.net

Submitted: Wednesday, July 26, 2006 10:33:17 PM -0700:

Delivery Notification: Delivery has been delayed

* 1853450283 ( 131.225.111.12 ) ( UUBE ) To: uube[at]devnull.spamcop.net

Submitted: Wednesday, July 26, 2006 10:33:14 PM -0700:

Delivery Notification: Delivery has timed out and failed

* 1853450220 ( 131.225.111.12 ) ( UUBE ) To: uube[at]devnull.spamcop.net

It looks like there's a server generating bounces after the fact, which can be a really bad thing if the incoming undeliverables have forged "From" addresses. Here's a quote from the FAQ:

Problem: Misdirected bounces

Description: When a mail server accepts a message and later decides that it can't deliver the message, it is required to send back a bounce email to the sender of the original message. These bounce emails are often misdirected.

Solution: Upgrade and/or configure your mail server software so that this situation is never encountered. Configure your software to either reject messages during delivery or accept them permanently. Do not let your software make choices about delivery after it has accepted a message. If you must accept delivery before you know the status of a message, then file it internally - do not send, forward or bounce it outside your organization. The errant message can be placed in a special folder or routed to your postmaster.

That's found at this URL:

http://www.spamcop.net/fom-serve/cache/329.html

But for more specifics, you might want to contact:

"deputies <at> spamcop.net"

DT

Share this post


Link to post
Share on other sites

ok, thanks for the info. is the 'Delivery Notification: Delivery has failed', the actual subject of the bounce message in question?

-kevin

Share this post


Link to post
Share on other sites

Yes, it appears that the server is accepting mail and then, later, sending a non-delivery message to the 'From'envelope. In spamthis is always forged. If you must reject do it with a 5xx at the time of the SMTP transacxtion.

Share this post


Link to post
Share on other sites

Ok,

I think I've found a way to make sure we refuse any emails to non-existant users according to our downstream machines. However, I don't see an easy way to prevent warnings from over-quota imap accounts and such. I don't think holding the outside smtp connection open until the message is actually written to the final message store is really viable in a high traffic enviornment, so how are people dealing with legit delivery failure messages?

Share this post


Link to post
Share on other sites
in a high traffic enviornment, so how are people dealing with legit delivery failure messages?

The "high-traffic" description is actually part of the key.

Please follow the "What is on the List?" link/entry in the SpamCop FAQ (links at the top of this very page) ... also found at http://forum.spamcop.net/scwik/SpamCopBlockingList .... Note the "ratio" involved of "traffic seen" as compared to "reports/spamtrap hits" ....

http://www.senderbase.org/?searchBy=ipaddr...=131.225.111.12

Volume Statistics for this IP

Magnitude Vol Change vs. Average

Last day ......... 4.1 .. -77%

Last 30 days ... 3.8 .. -90%

Average ......... 4.8

SenderBase's "Magnitude" Explained

The "legitimate" reasons also would suggest that SpamCop.net reporting would not be involved, spamtraps not hit, etc ....

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×