Blocked at sorbs b/c of rejected mail

SORBS is irrelevant. Nobody has cared about them in a long time. If you have mail being blocked by a recipient server because of SORBS then I highly recommend using a gmail account to tell the recipient server admin that SORBS is of little value due to the high FP rate and impossible criteria.

As for the message in question, seeing the full logs for the two message IDs may be helpful. Try grepping the logs for 'BBA201BBE1' and 'ECA261BBED' then posting the results here.

I've heard that SORBS is useless, my concern was that even so, I might not realize if someone is using them.

mikeage@linode /tmp$ grep ECA261BBED mail.log*
mail.log:Nov  5 09:08:01 linode postfix/cleanup[914]: ECA261BBED: message-id=<20091105070801.ECA261BBED@linode>
mail.log:Nov  5 09:08:01 linode postfix/bounce[938]: BBA201BBE1: sender non-delivery notification: ECA261BBED
mail.log:Nov  5 09:08:01 linode postfix/qmgr[3621]: ECA261BBED: from=<>, size=35510, nrcpt=1 (queue active)
mail.log:Nov  5 09:09:02 linode postfix/smtp[916]: ECA261BBED: to=<amplitudeuoh@clipmove.com>, relay=none, delay=60, delays=0/0/60/0, dsn=4.4.1, status=deferred (connect to grey-area.mailhostingserver.com[209.62.85.74]:25: Connection timed out)
mail.log:Nov  5 09:17:36 linode postfix/qmgr[3621]: ECA261BBED: from=<>, size=35510, nrcpt=1 (queue active)
mail.log:Nov  5 09:17:56 linode postfix/smtp[1233]: ECA261BBED: to=<amplitudeuoh@clipmove.com>, relay=grey-area.mailhostingserver.com[67.15.149.233]:25, delay=595, delays=575/0.05/20/0.09, dsn=5.7.1, status=bounced (host grey-area.mailhostingserver.com[67.15.149.233] said: 554 5.7.1 <>: Sender address rejected: Access denied (in reply to RCPT TO command))
mail.log:Nov  5 09:17:57 linode postfix/qmgr[3621]: ECA261BBED: removed
mikeage@linode /tmp$ grep BBA201BBE1 mail.log*
mail.log:Nov  5 09:07:58 linode postfix/smtpd[911]: BBA201BBE1: client=83-64-133-130.feldbach.xdsl-line.inode.at[83.64.133.130]
mail.log:Nov  5 09:07:59 linode postfix/cleanup[914]: BBA201BBE1: message-id=<000d01ca5de6$b4652830$6400a8c0@amplitudeuoh>
mail.log:Nov  5 09:08:01 linode postfix/qmgr[3621]: BBA201BBE1: from=<amplitudeuoh@clipmove.com>, size=33236, nrcpt=1 (queue active)
mail.log:Nov  5 09:08:01 linode postfix/smtp[916]: BBA201BBE1: to=<mikeage@gmail.com>, orig_to=<avodah@mikeage.net>, relay=gmail-smtp-in.l.google.com[209.85.212.43]:25, delay=3.3, delays=2.5/0/0.11/0.66, dsn=5.7.0, status=bounced (host gmail-smtp-in.l.google.com[209.85.212.43] said: 552-5.7.0 Our system detected an illegal attachment on your message. Please 552-5.7.0 visit http://mail.google.com/support/bin/answer.py?answer=6590 to 552 5.7.0 review our attachment guidelines. 9si2474704vws.88 (in reply to end of DATA command))
mail.log:Nov  5 09:08:01 linode postfix/bounce[938]: BBA201BBE1: sender non-delivery notification: ECA261BBED
mail.log:Nov  5 09:08:01 linode postfix/qmgr[3621]: BBA201BBE1: removed</avodah@mikeage.net></mikeage@gmail.com></amplitudeuoh@clipmove.com></amplitudeuoh@clipmove.com></amplitudeuoh@clipmove.com> 

Usually mail servers tell you why they're rejecting your email when they do. For instance, the last one there says you sent an attachment that Google, in their infinite wisdom, decided its users don't need. The other rejection doesn't say anything about Sorbs, so it could be something as simple as an invalid email address.

Right, but those weren't messages I sent [myself]. I have postfix set up to forward mail to my gmail account; gmail rejected them, they got bounced back, and the recipient [who might not have been the one who connected in the first place] complained via SORBS

If those are complete logs then it looks like a few things happened:

1) someone at 83-64-133-130.feldbach.xdsl-line.inode.at[83.64.133.130] pretended to send a message from amplitudeuoh@clipmove.com to avodah@mikeage.net

2) Your server accepted this message and tried to forward it to mikeage@gmail.com

3) gmail rejected it (bad attachment; virus?)

4) You sent a bounce message to amplitudeuoh@clipmove.com. The nature of the bounce message means that it would have contained the original bad attachment (virus?)

Congratulations, you attempted to send a virus to an innocent. This process is commonly known as "backscatter".

You need to be very careful when forwarding mail on like this.

It loooks like you're wildcard forwarding all email sent to mikeage.net onto google. Are you? If so, why not set up a google-apps account and have the mail go directly there. If you have a reason to want the mail to go to your linode first, then set up specific forwarding rules for each mail address you actually use (don't wildcard). That'll cut down on backscatter a lot.

That's my understanding as well. However, in this case, avodah@mikeage.net is a perfectly legitimate address, which sometimes receives spam.

The way I see it, there are three things I could be doing

1. Reject the original message since 83-64-133-130.feldbach.xdsl-line.inode.at isn't authorized to send mail from amplitudeuoh@clipmove.com. The problem with that, of course, is that there's no good way to do that

2. Not send bounce messages if gmail rejects it. This seems like a reasonable option [as it, my server shouldn't ever bounce messages on it's own; all addresses are either forwarded or sent silently to /dev/null

3. Strip the attachment from the bounce [probably the most standards compliant thing to do].

Any suggestions for either achieving one of these goals, or another option?

[incidentally, I forward most of my email on to gmail, but not all, which is why I want to have it go via my VPS]

1. You can use SPF.

-bash-3.2# host -tTXT clipmove.com

clipmove.com descriptive text "v=spf1 -all"

If you had SPF enabled on your server, it would reject all email from clipmove.com, since that domain is not permitted to send email.

2. Because of SPF, I would rewrite the sender to a bit bucket in your VPS. That way, any bounces will be discarded. This rewrite is also important so that Google doesn't apply the SPF rules of senders to your IP address and toss the mail in the spam bucket cause your IP isn't allowed to send email for that domain.

Can you elaborate a little more on your second point? I've learned that SPF totally breaks the concept of forwarding [and indeed, I see that gmail notes, for each message, that mikeage.net is neither permitted or denied to send messages on behalf of whoever the original sender is]. How can I do this using postfix?

I used to use sendmail and procmail. Not sure if it works with postfix.

/home/barkerjr/.procmailrc:

:0 fw

• !^X-Loop: barkerjrexample@gmail.com

| /usr/bin/formail -A'X-Loop: barkerjrexample@gmail.com'

:0 A

! barkerjrexample@gmail.com

Anti-spam and anti-virus on receiving is a good start, so you don't even accept the message (if you don't accept it then you don't generate a bounce message; you're not responsible).

Not bouncing stuff you (fail to) relay is really important and is the best answer (because some things will get through the anti-spam rules).

Stripping out attachments is good, but you'll still be sending backscatter, so I don't rate that as a priority.

How would I go about not generating a bounce for messages that are rejected by the forwarding rule using postfix?

@mikeage:

How would I go about not generating a bounce for messages that are rejected by the forwarding rule using postfix?
I'd look at the softbounce option.

http://archives.neohapsis.com/archives/ … /1404.html">http://archives.neohapsis.com/archives/postfix/2002-04/1404.html

Or you could use exim which is designed to behave appropriately.

Xan – how does exim behave "appropriately"? What does it do that Postfix does not / cannot?

To be honest I don't know much about Postfix. But from this discussion, the links therein, and some Googling, it looks like Postfix isn't set up to reject mail at SMTP time, which is far and away the very best time to reject mail.

I also know that when setting up my exim server, it was quite easy to plug it into spamassassin and clamav, and simply turn away evil mail at the gate, rather than let it in, delete it, and generate a bounce that does more harm than good.

Actually, that's all quite easy to do [although note that in postfix terms, that's smtpD time [smtp refers to outgoing].

I don't want to do that, however; why should I burden my linode 360 with clamav and spamassassin; both of which can be slow and memory intensive. I let Google handle that, and I have no problem silently dropping spam mail.

The goal is to either suppress the bounce that comes from forwarding, or generate a cleaner bounce. Even with exim, if I forward a message and the forwarded recipient rejects it [maybe they reject an extension that your scanner permits?], you would have the same problem

Ah, I see, I had misunderstood your problem.

What I've found useful is to bounce back to the same gmail address. It'll bounce back and fourth a few dozen times, but eventually the attachment will be wrapped in enough attachments for gmail to no longer detect it. Then it'll be delivered.

Interesting idea, except that I probably don't want the message; I just don't want to bounce back some virus infested attachment to some poor Joe [who doesn't/won't/can't use SPF].

@Xan:

To be honest I don't know much about Postfix. But from this discussion, the links therein, and some Googling, it looks like Postfix isn't set up to reject mail at SMTP time, which is far and away the very best time to reject mail.

postfix has quite a few built-in tests that can be done at smtp transaction time (sender address verification, valid recipient, dns resolving, valid HELO, RBL checks, relaying, simple regex checking of message contents) and has the ability to delay transactions while backend processing is done (eg virus check, anti-spam).

Yesterday my linode rejected 27,000 messages at SMTP time, and only accepted 242 messages. (And that's without A/V or antispam filtering; I do that later with spamassassin and filter results into a local spambox).

This is a pretty good howto on implementing Postfix sanity checks. I also recommend greylisting unless you absolutely cannot tolerate a few minutes' delay in e-mail (in which case you probably shouldn't be using e-mail to begin with). We are doing absolutely no content-based filtering (e.g., SpamAssassin or ClamAV) and don't even use any DNSBLs like the howto describes, and still only a few spam messages per day get through.

FYI – I added greylisting, and saw my spam [as identified by gmail] drop from ~100/hr -> 1 in the past 8 hours!

OK; I found a workaround; I set bouncesizelimit =5000, and now all those larger messages [containing the executables, etc] are replaced by their headers only [which is sufficient in a bounce, IMHO]

Glad it worked for you, and nice tip about bouncesizelimit - wasn't aware of that option.

I'm actually now using greylisting + SPF + reject invalid HELO's, and I only see a few unwanted messages getting into the system at all, so odds are that this will wind up being unnecessary ;)

For some reason, though, Google thinks that my messages which are now being forwarded via procmail [to handle SPF correctly] are more likely to be spam… almost 20% of my spam folder (still, < 5 /day) are actually real messages.