When I check up an IP with whois tool, I'll get the result with one of the columns named 'roles'. The value of the 'roles' column can be 'abuse', 'technical' or 'administrative'.
It's easy to understand the meaning of 'technical' and 'administrative', but is there anyone who know what does 'abuse' mean here?
Thanks a lot.
role may be used to determine the type of contact that the node describes. There are several types of contacts, such as: administrative, technical, owner, etc.
The term "abuse" refers to a recipient that is intended to report complaints about possible illegal use of that IP address. For example, if the IP is used to send SPAM emails, or as part of some kind of frauds.
This is similar to the scope of the abuse# email in a domain.
Related
I am new to sipp and network concepts i got a contact header
"Fin Tax" <sip:b2fdfc58-b7f2-a482-572c-8dbc1aae24#10.195.1.41:5060>;+
"ip.instance="urn:uuid:00000000-0000-0000-0000-34db8dc64>";+
u.sip!devicename="ATA34DBFD8DC64"4DBFD18DC64";+u.sip!model.cc.co.com="681"
Can you explain this contact paramerter i know the first part uri but what are next parameters
First parameter is +sip.instance (the double quote after + in the example above is a typo for sure), which is defined by IETF, it can be found in SIP Outbound (RFC5626) and GRUU (RFC5627):
https://www.rfc-editor.org/rfc/rfc5626
https://www.rfc-editor.org/rfc/rfc5627
Its purpose is to identify uniquely a device, independent of contact address (which can change in case of roaming around wifi hotspots or 4G/5G networks) or multiple connections, but contact addresses can also overlap when devices are located in private networks using same IP range.
Usually its value is build using a UUID (universally unique identifier), which should reduce the risk of duplicate values for users with multiple devices. Its uniqueness allows SIP Registrar Server to identify what contact record to update or remove when processing REGISTER requests from the same device.
The next two parameters prefixed with +u.sip! seem to be custom parameters set by the sending SIP UA. They look like specific to some CISCO equipment, probably a gateway. In general, SIP specifications tell that custom parameters can be ignored by receiving UA, if it does not know how to interpret them.
I have an SaaS application in the pipeworks.
One of the things that has me a bit confused is the best way to manage the stable of Austalian suburb and state data across multiple databases (this applies to any country as each country has a list like this).
For example in Australia you have Australian Postcode list that links all the postcodes to the suburbs and you can use that to create a dropdown for state, suburb and postcode etc.
An example of the CSV of australian postcodes can be found HERE.
So you can upload a csv file for example but the problem remains..
Whats the best way to hold this data.. its common to all databases where you have a person, client, employee etc..
Do you replcate it in each database? Is there a better way than having redundant stores of data..
Best way to implement it..
There are several options and considerations I would look at for this problem. Some considerations:
Number of address rows expected
Whether a client database is concerned with prefill/validated international addresses
Whether the client system is web connected or can operate in isolation
Are these databases/systems hosted by you or distributed to individual clients? (SaaS implies "Web" and "Hosted by You" to points 3 & 4)
How critical address integrity is.
For smaller systems, a simple option for address systems is to de-normalize the address data (state, postcode, suburb) and consider using a central lookup database/service, either under your own control or a third party. The denormalized address table would contain the text fields for the State, Postcode, Suburb etc. rather than FK values (stateId, suburbId, etc.) This avoids needing to store lookup tables in every client DB, just one Lookup DB or leave that to a 3rd party service.
The advantage of a third-party lookup is that keeping it up to date with new areas and changes is handled for you. Third party services would require a web connection, and you have to factor in the risk of their service being down or a web connection being unavailable. Larger systems with millions of addresses might benefit from normalizing the address table, so the "cost" of replicating suitable address lookup tables might be worthwhile. You can still a central service to look up addresses, then resolve whether the client DB already has a StateId, SuburbId etc. for the respective state/suburb for that post-code before inserting one if necessary. (Cutting down the number of rows each client DB needs to address values that are actually used)
In that last example you might have lookup tables for State and Suburb linked to PostCodes, linked to Country. Country would default to the target, maybe be an optional selection for international addresses. The user provides a post code to the service which returns suburbs, they select a suburb. The address validation service could go as far as to validate the street address. When you're happy an address is "valid" and ready to be saved, you search your local State, Suburb, (even Street) tables for matches for that PostCode, if found use those FKs, otherwise insert new entries and link the FK.
Using a separate service, or services would be my consideration especially if you need to support validating/storing international addresses. For instance if the client is in Australia but regularly has address information for New Zealand. Storing entire address validation tables could get rather large if clients could be resolving addresses for many countries. (I.e. European countries and neighbours) You can write a Façade service to support different 3rd party address validation providers and/or homemade implementations with a standard interface.
If a system has to operate in isolation of an internet connection then you'll probably be stuck with each database having one or more local data sources to resolve address information.
Data integrity of address information is a separate concern you might want to consider. In some systems you need to validate that an address is recognized and don't want to allow invalid combinations or detect unexpected changes. Services that validate a particular address can provide unique IDs for an address that you can store as part of your address information. (These often tie into geocoordinate solutions where you want to quickly direct a map service to a particular location) Alternatively, if you successfully look up an address then validate that the address information is valid, even if just the country, post code, and suburb, you can create and store a hash of those values to check for tampering. (I.e. someone or some system changed a field to make the address invalid, the combined address won't match the stored hash) Addresses can be checked before use and flagged if not valid.
My DNS provider works perfectly for A records.
I am having great difficulty understanding the syntax of SPF records. I have no prior experience.
The DNS provider supports SPF records and it has two control boxes for information: 'Name' and 'SPF data'.
The A record which functions fine looks like this:
Name: potsandpins.info
IPV4 Address: 45.61.228.207
The SPF record which is giving me no joy looks like this:
Name: potsandpins.info
SPF Data: "v=spf1 a -all" (including the quotation marks)
My emails are received with a red flag in Gmail which says 'Gmail couldn't verify that potsandpins.info actually sent this message'.
Can anyone suggest anything as I've tried all sensible permutations?
You don't seem to currently have an SPF record for potsandpins.info maybe you deleted it because you ran into trouble. Anyway, think of the SPF as a whitelist of any IP addresses or hosts you've given permission to send email on your behalf.
The name would be either the root domain, sometimes designated by the #, or a hostname, foo, which you'd use if you were sending email out as example#foo.example.com.
The SPF data would be the version number (v=spf1), then mechanisms (e.g., a), and then the ip addresses or hosts you'd like to authorize, then the qualifier such as -ALL, which intends a hard fail. You may want to back off from that using ~ALL for now, which intends a softfail. I think it's better to be specific in SPF records as then they're easier to follow exactly what they're authorizing.
Here's an example SPF record. Let's say you wanted to authorize 192.0.2.10 and Google.
v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all
Let's say you wanted to authorize a range of IP addresses and MailChimp:
v=spf1 ip4:192.0.2.0/24 include:servers.mcsv.net ~all
Here's a good article on common mistakes in SPF records.
Then it's important to validate your SPF record using a tool such as the SPF Survey. I like this tool because it gives more detailed, actionable error messages when there's a problem.
if you post the full headers of an example email and indicate any other services you use to send email, then it would be possible to provide more specific advice. For future reference, it's best to provide more details when you post to Stack Overflow as that makes it easier to help. I tried in this post but the information you provided limited how specific the answer could be.
Also, for future reference, it's best to post using example.com rather than a real domain name and use IP addresses from an IPv4 block reserved for documentation.
The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation.
Anyway, I hope this helps.
When designing an internation registration form how should I be asking for a user's information. Should name be [First, Last] or [Common, Surname] or simply [Name]. Does first and last name make sense for all names?
When asking for state and zipcode what would alternative terminology be, should I even be collecting this information for some countries?
We're recently getting into international users and methods and I'm hoping someone with experience can weigh in on the proper fields and labels that would be present in a solid international registration form.
I would reccomend just a single input for name, not all names are logically separated into just two parts, some people have just one name (such as Teller, and if used for addresses, the name may be a company name). Labeling is complicated since first and last name is not the same as given and family name, if names in your language is normally in which field should the first/family name go and the last/given name go?
For an address input you need:
Name/Company: <text box; no validation or munging>
Address: <Multiline textbox; no validation or munging>
Country: <text box or select-box if you're paranoid>
Making it more detailed and you're creating problems for foreigners.
The only thing your local post service need for a foreign address is the name of the country. The rest is country specific and may include several fields or in some cases something like "behind the church in the woods" etc.
Do not include zip code or anything country specific like that unless the user has chosen a country you have extensive knowledge about. People tend to know how to type their address in a free form text area, but they may actually mess it up if they have to force their address into foreign fields.
The worst you can do is silently discarding invalid fields. That happened to me when registering my address (in Norway) for a magazine subscription from USA. The norwegian addres format is:
<Name or company>
<Street name> <house number>
<post code> <city or suburb>
NORWAY
But when trying to force these fields into the closest equivalent in a very US-centric form they ended up mailing it to:
<my name> Oslo/OSLO//<And a lot of garbage letters and symbols>
/NORWAY
It eventually arrived, but it was a month delayed. It probably helped that I have a unique name, and that we're only about 5 million people in Norway. I doubt it would have arrived if I my name was "John Smith" and lived in New York and some web form had munged it to John Smith NY/New York;/ USA///
Sorry for the long rant ;)
I would suggest just the name, so that user could enter whatever seems right.
As for State, I quite don't understand what you need this information for. But I am not U.S. citizen, so...
Two address lines (without implied format), zip code (terminology is OK, but do not try to validate) and country name should be sufficient. The problem with "States" is, some countries do not use such concepts (either at all, or use different regional split concepts, i.e. in Poland it is voivodship, in England it would be county, etc.). Again, I wouldn't use such details.
How you accept the user data is based on what you want to do with it. Having said that
Name: This is also country specific but based on the suggestions I've got "family name" and "given name" are generic/common across any country. Some names have multiple "family name"'s.
Address: Different countries have different address formats. You can get different format information here
As a non-US resident, who has a very non-standard address (live on a boat, which requires additional address information, and very often does not have a Royal Mail standarised address) I do find that US-centric registration forms are very irritating. As far as name goes, I have found first and last name appropriate. For addresses I would consider either leaving labels off for most lines or labelling them innocuously as "address line 1", etc. In addition make sure that there are a number of such lines; the dialog box is long enough to accept multiple fields; and the dialogs will accept address delimiters such as comma. The only ones I would leave as they often displayed are Town/City and Country. Zipcodes should not be referred to as such - the minimum courtesy I would expect from a registration form is a request for Zip/Post code.
Though not directly related to registration forms, I have previously provided a (very long) answer to a question on validation/normalisation of international data. It is not a simple topic.
I have been asked to implement some email address validation on a web app - I'm sure we've all been there a thousand times... however, this time I have been asked to do an MX Lookup on the domain to see if it accepts emails.
Does anyone know of any potential problems with doing this? Is an mx lookup a reliable way of finding out if a domain accepts email? are there any edge cases where a valid email address could fail an MX lookup check?
Thanks for your advice!
are there any edge cases where a valid email address could fail an MX lookup check?
Yes, in that where there is no MX record, MTAs fall back to using the A record instead. So only allowing MX records would fail a class of mail servers that work in the real world.
Allowing any name with an MX or A record at least detects obvious mistypings that result in NXDOMAIN. However it will still allow mistypings that end up at squatter sites. A further step for addresses resolved by A records might be to check where port 25 is accepting connections on that address.
You can only check if there is an mail server registered for the domain.
If the server also accepts mails and if the address is valid (not syntactically but in the sense that there exists a inbox for it and so on...) you will only find out when sending the e.g. registration email
sample on how to do this in PHP
function mailserver_exists($email) {
list($user,$domain) = split('#',$email);
//included check for 'A' after [comment from bobince][1]
return checkdnsrr($domain,'MX') || checkdnsrr($domain,'A');
}
if(domain_exists('joe#foreigndomain.xx')) {...} else {...}
Yes you can use 'TinyTim#192.184.165.13' too. The PHP documentation for checkdnsrr(host, type) states
host may either be the IP address in
dotted-quad notation or the host name