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
Full Version: Help debugging spamtrap Hits
QUOTE(kevdude70 @ Aug 30 2006, 02:06 PM) 
the machine in question is:
mailgw2.fnal.gov 131.225.111.12
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:
QUOTE
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.
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
ok, thanks for the info. is the 'Delivery Notification: Delivery has failed', the actual subject of the bounce message in question?
-kevin
-kevin
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.
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?
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?
QUOTE(kevdude70 @ Aug 31 2006, 03:36 PM)
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 ....
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.