Web Hosting Talk : Web Hosting Main Forums : Hosting Security and Technology : mail rejected

[rblproblem]

the smtp server have ptr/a records setup, smtp auth enabled, isn't on any blacklist and never was. when sending mails to certain recipients mail returns with 554 error stating the ip is blacklisted. the referencing ip is dynamic ip used by sender, not the server itself. i inspected the headers and server ip is listed in one of the from fields, the client ip is listed under another from fields.
how do i prevent this error from happening? i don't want to relay my smtp server which is perfectly fine to isp smtp server. why isn't the receiving smtp checking the last from field which is server's ip but instead bounce the message because the client is on dynamic ip?
if you have any solution, please share, regardless of the mta you're using. i'll make the appropriate changes in my configuration. i'm thinking it's not my fault but receiving smtp fault because i can send using the same configuration to some other recipients who have spamhaus checking enabled and everything works fine because the server checks on the my server ip and not on the client's ip.

[Rekhatitus]

Hi,

which is the mail server you are using?

[ServerManagement]

Some blacklists don't remove you until you manually request delisting. So it can be from a previous owner of the ip that it is still blocked from. Contact the blacklist you are being blocked by and ask to be delisted.

[rblproblem]

i don't think this is related to the mta i'm using. the problem is that recipient's smtp inspects the client ip address instead of the smtp server ip which is trying to deliver the message. the server ip is not blacklisted and it never was.

it's something like this:
From: server....
From: client....

the client is on dynamic ip and that it the reason why the mail is bounced. the server is on static non-blacklisted ip.
i still believe the problem is with the recipient server as it seems it's checking all the from headers and not only the last one (my server's). i overcame this problem by rewriting the headers prior dispatching the mail, but came here to check what else can be done because it's generally not a good idea to mess with the headers.

[mugo]

Many providers, especially AOL, and other big boys, subscribe to dymanic IP lists, and block them by default. You technically arent' on a blacklist, not a search-able one anyway, but you are still on a known dynamic IP network (DSL / Cable, etc) which have a very bad rep for spammers abusing.

The only way to get off of this is to follow procedures at the big boys, get them to white list you and setup a feedback loop. If you are on truley dynamic IPs, and don't have static or sticky IPs in side a usually-dynamic block, you may never be able do go this far, as they need a set block, and not TW Cable class B network for instance...they just won't do it.
Most dynamic networks offer static/sticky IPs, but it may cost you extra $$.

[rblproblem]

i have no intention for paying anyone as my server ip when checked against many blacklists doesn't appear to be listed anywhere. for now i'm doing headers rewriting and everything is working fine, but i might drop that as well and simply don't care about those providers with questionable policies. after all it's not my problem.

[mugo]

I don't think you understood what I meant on the money...
If you are receiving a dynamic IP from your ISP, then you are most likely on dynamic IP blocks, independent of the comprehensive blacklist searches on the 'net you may find, like MXToolbox's search. Theses lists don't show up as blocks...Yahoo, for instance, has already done the legwork to find all of AT&T or TW's dynamic IP ranges. Then, they block them from handing off directy to their SMTP servers. Nothing to do with reputation vs. SPAM, rDNS, or HELO domains.

The money I was referring to was to your ISP for static / sticky IPs so that you could possibly be white listed with AOL, Yahoo, etc. It is possible to get on a feedback loop and have them unblocked, but only with non-moving targets. It also makes it easier to hit a non-moving MX record on the incoming.

You can thank the "questionable policies" on all the dynamic IP range spammers over the years. I block dynamic IP ranges on our DC mail servers also, so, I don't really agree on the "questionable" part. Dynamic IPs are 95% either spammers or hobbiests when it comes to running mail servers. If they aren't serious enough to either get statics, or host mali from a DC or mail service, then, oh well, their problem. Must not be important enough to warrant.

[rblproblem]

the client (on a dynamic ip which is blacklisted by default) connects to the server (smtp auth required). then the server connects to the recipient's smtp server and gets refused not because the smtp server is blacklisted but rather because the client is on dynamic ip.
i can understand the bounce if i connected directly to the recipient server, but the reasons for this i still can't understand.

just as an example, the same client using the same outgoing smtp can send mail without problems to other recipients (server guarded with spamhaus for instance). the problem here is that i don't understand why is this server checking the whole route instead only the last one.

client -> outgoing smtp -> recipient smtp

[mugo]

Clarify a bit here...is the Mail server in question, that you are doing smtp auth through, YOUR mail server, itself using dynamic IPs?

If you are just handing off to your ISPs mail server, using smtp auth, and you are getting a bounce, then something is wrong at the ISP's level. It should not matter what client is handing off to it, as long as you have authority to send through that server.

I was understanding this to mean you have an SMTP server that uses a dynamic IP (and I would assume some dynamic dns service), and that server was getting rejected when handing off to other up-stream servers.

[rblproblem]

client: dynamic ip which is blacklisted by default
smtp a: my server, static ip, used for some time now already, not blacklisted, as to best of my knowledge never was blacklisted, smtp auth required
smtp b: recipient server

flow: client -> smtp a -> smtp b

smtp b rejects mail not because of the smtp a but because of the client. bounced message contain objections to the client ip, not smtp a ip.

I don't care about smtp b anymore. it's their problem not following the protocols. i came here just to check if there is any valid reason why smtp b would accept smtp a but reject client even though client never directly connected to smtp b.

sorry, lot of text.

[mugo]

No prob, takes that to figure out what's going on..got the jist of it now.
What mail server are you running?

There is no valid reason, as smtp b should only care about smtp a. you are correct on that for sure.
Looks like someone upstream is being a bit TOO anal on header inspects.

You are absolutely sure it's the clients IP being rejected? Is your mail server in a DC, or is it on Cable / DSL?

[rblproblem]

yes, i'm 100% sure the problem is with the client ip. as a part of diagnostics i introduced header rewriting on smtp a. when headers related to the client ip was stripped the mail got delivered (client -> smtp a -> smtp b). when i reverted the headers rewriting mails are rejected again.
server is in a dc, a well known one.

i've pinpointed the exact header which is causing the bounce. i don't think my server software is related to the problem, but i'll check it on both linux and windows servers and a few client agents, just to shed some more light on it.

if it matters, smtp b is using barracuda for filtering.

the main reason for coming here was to confirm that smtp b should only verify smtp a, and not go deeper through the chain.
beside ip the only thing that pops to my mind is that client header does not contain fqdn but rather windows computer name. it shouldn't matter because smtp b shouldn't be checking that header at all, but that is the only possibility left, in my opinion.

smtp a have a fqdn, ptr record, a record point back to ptr record, ..... in short: i'm quite sure smtp a is fine.

[mugo]

I think you just hit on something...client doesn't have FQDN in the header..
and, from barracuda...

•
SMTP recipient verification
. By default, the Barracuda Spam Firewall rejects messages if the downstream mail server does not accept mail for that recipient.

SMTP auth get's you around many things that would normally halt mail, and I am willing to bet that the barracude things the downstream *shouldn't have* accepted a non-FQDN stamp.

[rblproblem]

i'll try modifying client to send fqdn instead of windows computer name. but the problem will still remain with all other clients beside mine as i can't go to each and every one of them and modify their configuration .
i should have browsed through barracuda site, and not let you do my job nevertheless, thank you for helping me on this one.

smtp c is guarded by spamhaus and the client -> smtp a -> smtp c works just fine, so i as well bet that the reason for smtp b rejection is like you suggested

i guess /thread