I started getting a number of emails though our server that are bombing out with the 553 malformed address error. Here is an example: 553 malformed address: <NPD.Survey.@emailfactory.net>
I know that the "." before the "@" symbol is causing the error but I don't know how to configure the sendmail.cf file to accommodate for this error.
Note: If you are the author of this question and wish to assign points to any of the answers, please login first.For more information on assigning points ,click
here
This post raises a lot of questions for me.
Is "NPD.Survey." a legitimate username for you?
What is it that you want sendmail to do? Deliver as is, or rewrite the address?
One last (retorical) question is... Why are you trying to fix this in sendmail? (and not where the malformed address is being generated)
Sorry, I obviously did not provide enough information.
These are not valid address on our systems. They are spam from outside sources to internal email addresses.
My systems are set to relay mail only from our domains. These emails are somehow getting through and would not be relayed except they fail with the 553 error before it gets to the decide not to relay them. Anyway, I'm tired of having to deal with them. I thought there was a way to modify the sendmail.cf file in Ruleset 3 or 4 to correct for this error. Thus I would not see them anymore.
There is more work in the Linux world on this than in the HP-UX world.
The good news is in late July, I'm inheriting a D320 box. The actual intent is self education, but what I plan to do for education is set up a web/mail serving doing exactly what you want to do.
5XX series messages should generate a reject; that is your relay should never accept the mail to begin with.
If you're front-ending an internal MX, and the internal MX is rejecting the relayed mail, resulting in queued mail on the front-end server, then your access rules on the front-end are too lax.
Give us version, etc. for sendmail on the front-end host, and we can make suggestions.
You didn't specify which version of sendmail you are running. However if you wish to block spam you might try the following changes to the sendmail ruleset:
FR-o /etc/sendmail.cR
Scheck_rcpt
# anything terminating locally is ok
R< $+ @ $=w > $@ OK
R< $+ @ $=R > $@ OK
# anything originating locally is ok
R$* $: $(dequote "" $&{client_name} $)
R$=w $@ OK
R$=R $@ OK
R$@ $@ OK
The caveat is mail must originate or terminate locally (on this host), with exceptions made for hosts listed, one per line, in /etc/sendmail.cR. (In this incarnation, this ruleset does not allow relaying within your domain, except for the hosts listed in /etc/sendmail.cR. Note carefully, you must list fully qualified host names for each host you wish to allow relaying.
Thanks All, since I am already using the access file to limit the relay, it should have been obvious to me to try there first. Sometimes you grab the shotgun when a fly swatter would do fine.
Printable version
